Enterprise Server 3.21 ist derzeit als Release Candidate verfügbar.

Bekannte Probleme mit Upgrades für deine Instanz

Sehen Sie sich eine Übersicht über Problemumgehungen für Probleme an, die sich auf den Upgradeprozess GitHub Enterprise Serverauswirken oder sich auf Ihre Instanz auswirken, nachdem Sie ein Upgrade abgeschlossen haben.

In diesem Artikel

Informationen zu Problemen, die bei GitHub Enterprise Server-Aktualisierungen bekannt sind

          GitHub ist sich der folgenden Probleme bewusst, die sich auf Upgrades auf neue Versionen von GitHub Enterprise Server auswirken könnten. Weitere Informationen finden Sie unter "Bekannte Probleme" in den [GitHub Enterprise Server Versionshinweisen](/admin/release-notes).

          GitHub empfiehlt dringend regelmäßige Sicherungen der Konfiguration und Daten Ihrer Instanz. Bevor du mit einem Upgrade fortfährst, sichere zunächst deine Instanz, und überprüfe dann die Sicherung in einer Stagingumgebung. Weitere Informationen findest du unter [AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-appliance) und [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance).

Aufheben der Pause bei Upgrades auf Version 3.15 und höher

Wir haben die Pause bei Upgrades auf die Versionen 3.15, 3.16 und 3.17 aufgehoben. Du kannst jetzt ein Upgrade auf 3.15.12, 3.16.8, 3.17.5 oder höher durchführen. Es wird nicht empfohlen, ein Upgrade auf frühere Versionen von 3.15, 3.16 oder 3.17 auszuführen. Als zusätzlicher Schritt wird empfohlen, die Systemkapazität vor dem Upgrade zu überprüfen. Weitere Informationen findest du unter Überprüfen der Systemkapazität vor dem Upgrade.

Das Supportfenster für die Versionen 3.14, 3.15, 3.16 und 3.17 wurde erweitert. Das Supportfenster für 3.13 bleibt unverändert. Das Abschlussdatum für die Versionen 3.14, 3.15, 3.16 und 3.17 wurde aktualisiert. Weitere Informationen finden Sie unter Veröffentlichungen von GitHub Enterprise Server.

In diesem erweiterten Supportfenster werden weiterhin Patches für 3.14, 3.15, 3.16 und 3.17 veröffentlicht.

Erforderliche Stammdatenträgergröße auf 400 GB erhöht

Die vorherige Anforderung zur Stammdatenträgergröße von 400 GB ab Version 3.15.2 wurde entfernt. Diese Anforderung basierte auf einer Analyse von Supportbundles und Supporttickets. Einige Faktoren (wie Protokolle) erhöhten die Last für den Stammdatenträger erheblich, was zu Geräteproblemen führte. Nach der Auswertung von Feedback, dass die Anschaffung neuer Hardware für viele Kunden eine Herausforderung darstellt, haben wir die Anforderung nun in einen schrittweisen Ansatz geändert. Es wird weiter empfohlen, ein Upgrade auf eine Stammdatenträgergröße von 400 GB durchzuführen. Dies gilt insbesondere für Kunden, die eigenständige Topologien oder eigenständige Topologien mit Hochverfügbarkeit verwenden. Wenn dir ein Upgrade auf eine Stammdatenträgergröße von 400 GB möglich ist, führe die folgenden Anweisungen aus.

Kunden, die eigenständige oder HA-Topologien verwenden, wird für neue Installationen ab Version 3.15 oder bei Upgrades auf 3.15 die Verwendung einer Rootdatenträgergröße mit mindestens 400 GB empfohlen. GitHub empfiehlt dringend, die Anleitungen in Speicherkapazität erhöhen zu folgen.

Nicht entschlüsselbare Datensätze

Wenn Sie ein Upgrade von GitHub Enterprise Server 3.11 oder 3.12 auf 3.13 oder von 3.12 auf 3.14 durchführen, treten aufgrund fehlender erforderlicher Schlüssel für die Entschlüsselung möglicherweise ein Problem mit unverschlüsselten Datensätzen auf. Dieses Problem lässt sich nur durch Löschen der nicht entschlüsselbaren Datensätze lösen. Die Art der Datensätze, die von diesem Problem betroffen sind, sind 2FA-Datensätze. Das bedeutet, dass du Benutzer möglicherweise bitten musst, die Zwei-Faktor-Authentifizierung (2FA) erneut zu aktivieren.

Vor dem Upgrade

Wenn Sie ein Upgrade von GitHub Enterprise Server 3.11 oder 3.12 auf 3.13 oder von 3.12 auf 3.14 durchführen, können Sie das Verschlüsselungsdiagnoseskript ausführen, um die unverschlüsselten Datensätze vorab zu identifizieren. Dieses Skript ändert keine Datensätze, bietet dir jedoch die Möglichkeit, die Auswirkungen zu verstehen und sie zu planen.

  1. Lade das Verschlüsselungsdiagnoseskript herunter. Du kannst einen Befehl wie curl -L -O https://gh.io/ghes-encryption-diagnostics verwenden, um das Skript herunterzuladen.
  2. Speichere das Skript im Verzeichnis /data/user/common der Anwendung.
  3. Befolge die Anweisungen oben im Skript, und führe es in der Anwendung aus. Wenn nicht entschlüsselbare Datensätze vorhanden sind, werden sie in /tmp/column_encryption_records_to_be_deleted.logprotokolliert. Alle hier protokollierten Datensätze konnten nicht entschlüsselt werden, da das System die Schlüssel nicht finden konnte, die zum Verschlüsseln der Datensätze verwendet wurden.

Beachte, dass diese Datensätze im Rahmen des Upgradeprozesses gelöscht werden. Das Skript warnt Sie über die Benutzer, die sich nach dem Upgrade erneut für 2FA registrieren müssen. Die Benutzernamen der betroffenen Benutzer werden in /tmp/column_encryption_users_to_have_2fa_disabled.log protokolliert. Diese Benutzer müssen sich erneut mittels 2FA registrieren.

Wenn das Skript auf unerwartete Probleme stößt, werden Sie aufgefordert, Kontakt aufzunehmen GitHub-Support. Fehler im Zusammenhang mit diesen Problemen werden in /tmp/column_encryption_unexpected_errors.log protokolliert. Wenn Sie sich in einer Notlage befinden und es Ihnen nicht möglich ist, die Benutzer zur erneuten Registrierung für 2FA zu bewegen, wenden Sie sich an GitHub-Support, um Hilfe zu erhalten.

Das Skript gibt „Erfolg: Verschlüsselte Datensätze OK“ aus, wenn die Schlüssel gefunden werden konnten, die den verschlüsselten Datensätzen zugeordnet sind. Diese Datensätze werden während des Upgradeprozesses entschlüsselt und beibehalten und erfordern keinen manuellen Eingriff.

Während des Upgrades

Wenn du nicht die Möglichkeit hattest, das Verschlüsselungsdiagnoseskript vorab auszuführen, enthält das Produkt Mechanismen zu deiner Unterstützung. Im Rahmen der Preflightüberprüfungen während des Upgradeprozesses werden nicht entschlüsselbare Datensätze erkannt und in /tmp/column_encryption_records_to_be_deleted.log protokolliert. Die Sequenz wird Sie über die Benutzer informieren, die nach dem Upgrade die 2FA erneut aktivieren müssen. Die Datensätze der betroffenen Benutzer werden in /tmp/column_encryption_users_to_have_2fa_disabled.log protokolliert.

Wenn nicht entschlüsselbare Datensätze erkannt werden, wirst du gefragt, ob der Upgradeprozess fortgesetzt werden soll. Wenn der Upgradeprozess fortgesetzt wird, werden die nicht entschlüsselbaren Datensätze gelöscht. Andernfalls wird der Aktualisierungsprozess beendet.

Wenn Sie während des Upgrades Fragen haben, können Sie sich an GitHub-Support. Wenn du die Zeit und die Gelegenheit hattest, dir einen Überblick über die Auswirkungen zu verschaffen, kannst du den Upgradeprozess wiederholen.