Problèmes connus avec les mises à niveau de votre instance

À propos des problèmes connus avec les mises à niveau de GitHub Enterprise Server

GitHub a connaissance des problèmes suivants qui pourraient avoir un impact sur les mises à niveau vers les nouvelles versions de GitHub Enterprise Server. Pour plus d’informations, consultez « Problèmes connus » dans les Notes de publication de GitHub Enterprise Server.

GitHub recommande vivement de sauvegarder régulièrement la configuration et les données de votre instance. Avant de procéder à une mise à niveau, sauvegardez votre instance, puis validez la sauvegarde dans un environnement intermédiaire. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance » et « Configuration d’une instance de préproduction ».

La taille requise du disque racine est passée à 400 Go

Pour les clients utilisant des topologies autonomes ou HA, il est recommandé que les nouvelles installations de la version 3.15 ou plus récente, ou les mises à niveau vers la version 3.15, utilisent un disque racine d'une taille d'au moins 400 Go. GitHub recommande vivement de suivre l’aide dans Augmentation de la capacité de stockage.

Enregistrements non chiffrés

Si vous effectuez une mise à niveau de GitHub Enterprise Server 3.11 ou 3.12 à 3.13, ou de 3.12 à 3.14, vous pouvez rencontrer un problème avec des enregistrements non déchiffreables en raison de clés requises manquantes pour le déchiffrement. La seule solution consiste à supprimer les enregistrements non déchiffreables. Les enregistrements concernés par ce problème sont les enregistrements 2FA, ce qui signifie que vous devrez peut-être demander aux utilisateurs de réactiver l'authentification à deux facteurs (2FA).

Avant la mise à niveau

Si vous mettez à niveau GitHub Enterprise Server 3.11 ou 3.12 vers 3.13, ou de 3.12 vers 3.14, vous pouvez exécuter le script de diagnostic de chiffrement pour identifier à l'avance les enregistrements non déchiffrables. Ce script ne modifiera aucun dossier, mais il vous donnera l’occasion de comprendre l’impact et de le planifier.

1. Téléchargez le script de diagnostic de chiffrement . Vous pouvez utiliser une commande telle que curl -L -O https://gh.io/ghes-encryption-diagnostics pour télécharger le script.
2. Enregistrez le script dans le répertoire /data/user/common sur l’appliance.
3. Suivez les instructions en haut du script et exécutez-le sur l’appliance. S’il existe des enregistrements indéchiffrables, ils sont connectés dans /tmp/column_encryption_records_to_be_deleted.log. Tous les enregistrements répertoriés ici n’ont pas pu être déchiffrés, en raison de l'impossibilité pour le système de trouver les clés utilisées pour crypter les enregistrements.

Notez que ces enregistrements seront supprimés dans le cadre du processus de mise à jour. Le script vous avertit des utilisateurs qui devront se réinscrire dans 2FA après la mise à niveau. Les identifiants des utilisateurs concernés sont connectés dans /tmp/column_encryption_users_to_have_2fa_disabled.log. Ces utilisateurs devront être réinscrits dans 2FA.

Si le script rencontre des problèmes inattendus, vous serez invité à contacter Support GitHub. Les erreurs liées à ces problèmes sont journalisées /tmp/column_encryption_unexpected_errors.log. Si vous êtes dans une situation grave et que vous ne parvenez pas à réinscrire des utilisateurs dans 2FA, contactez Support GitHub pour obtenir de l’aide.

Le script affichera « Succès : enregistrements chiffrés OK » s’il est en mesure de trouver les clés associées aux enregistrements chiffrés. Ces enregistrements seront déchiffrés et conservés pendant le processus de mise à jour et ne nécessitent aucune intervention manuelle de votre part.

Pendant la mise à niveau

Si vous n’avez pas la possibilité d’exécuter le script de diagnostic de chiffrement à l’avance, il existe des mécanismes dans le produit pour vous aider. Les vérifications de préversion pendant le processus de mise à niveau détectent les enregistrements non chiffrés et les connectent dans /tmp/column_encryption_records_to_be_deleted.log. Le script vous avertit des utilisateurs qui devront se réinscrire dans 2FA après la mise à niveau. Les enregistrements des utilisateurs concernés sont connectés dans /tmp/column_encryption_users_to_have_2fa_disabled.log.

Si des enregistrements non chiffrés sont détectés, vous serez invité à déterminer si vous souhaitez poursuivre la mise à niveau ou non. Si vous poursuivez, le processus de mise à niveau supprime les enregistrements non déchiffreables. Sinon, le processus de mise à niveau se termine.

Si vous avez des questions pendant la mise à niveau, vous pouvez contacter Support GitHub. Une fois que vous avez eu le temps et l’occasion de comprendre l’impact, vous pouvez retentant la mise à niveau.

Mise à niveau de la version 3.14 vers la version 3.16.0

Si vous utilisez la version 3.14 de GitHub Enterprise Server et que vous avez activé les produits de sécurité par défaut au niveau de l’organisation, vous ne pouvez pas effectuer de mise à niveau directe de la version 3.14 vers la version 3.16.0. Pour déterminer l’éligibilité de votre mise à niveau, exécutez la commande suivante :

ghe-console -y
Organization.any? { |o| [o.vulnerability_updates_enabled_for_new_repos?, o.security_alerts_enabled_for_new_repos?, o.dependency_graph_enabled_for_new_repos?, o.advanced_security_enabled_on_new_repos?, SecretScanning::Features::Org::TokenScanning.new(o).secret_scanning_enabled_for_new_repos?, SecretScanning::Features::Org::PushProtection.new(o).enabled_for_new_repos?].any? }

Si la commande retourne true, une mise à niveau directe de la version 3.14 vers la version 3.16.0 échouera. Nous vous recommandons d’attendre le prochain patch de la version 3.16 pour effectuer la mise à niveau.

Vous pouvez également passer à la version 3.16.0 dès maintenant en effectuant d’abord une mise à niveau de la version 3.14 vers la version 3.15, puis de la version 3.15 vers la version 3.16.0.