jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-09 06:03:09 -05:00
Code Issues Projects Releases Wiki Activity

Merge pull request #51621 from github/deprecate-3.9

Browse Source 
Deprecate GHES 3.9
This commit is contained in:
Rachael Sewell
2024-07-11 09:52:49 -07:00
committed by GitHub
parent d1340e2c8c 29ae0de977
commit 906c13f767
8 changed files with 5 additions and 194 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
content/admin/backing-up-and-restoring-your-instance/index.md
View File

@@ -8,6 +8,7 @@ topics:
- Enterprise
children:
- /configuring-backups-on-your-instance
- /known-issues-with-backups-for-your-instance
redirect_from:
- /admin/backing-up-and-restoring-your-instance/known-issues-with-backups-for-your-instance
---

114
content/admin/backing-up-and-restoring-your-instance/known-issues-with-backups-for-your-instance.md
View File

@@ -1,114 +0,0 @@
---
title: Known issues with backups for your instance
intro: 'See an overview of workarounds for issues that impact the backup or restoration process for {% data variables.product.prodname_ghe_server %}.'
versions:
feature: backup-utilities-encryption-bug
type: overview
topics:
- Enterprise
- Troubleshooting
- Backups
shortTitle: Known issues with backups
redirect_from:
- /admin/configuration/configuring-your-enterprise/known-issues-with-backups-for-your-instance
---
## About known issues with {% data variables.product.prodname_ghe_server %} backups
{% data variables.product.company_short %} provides workarounds for the following issues that could impact backup or restoration of data for a {% data variables.product.prodname_ghe_server %} instance. For more information, see "Known issues" in the [{% data variables.product.prodname_ghe_server %} release notes](/admin/release-notes).
{% ifversion backup-utilities-encryption-bug %}
## Users cannot sign in after restoration of a backup
{% note %}
**Note:** This known issue has been fixed in {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.9 %}3.9.1{% endif %}.
{% endnote %}
If you used {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %} to back up an instance running any release in the {% data variables.product.product_name %} 3.7{% ifversion ghes = 3.9 %} or 3.8{% endif %} series, after you restore the backup to a new instance, users cannot sign in. Though users cannot sign in, the backup itself is unaffected and all data is intact.
After you restore an existing backup affected by this issue, you can resolve the issue by modifying the configuration on the new instance.
### Restoring from an existing backup
If you've restored an existing backup from {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.9%}3.7.0, 3.8.0, or 3.9.0{% endif %} to a new instance and users cannot sign in, you must output configuration data from the source {% data variables.product.product_name %} instance and adjust the configuration on the target instance.
To ensure users can sign into the new target instance, ensure that your environment meets the following requirements.
* The source {% data variables.product.product_name %} instance must be running and accessible via SSH.
* You must have an existing backup from {% data variables.product.prodname_enterprise_backup_utilities %} {% ifversion ghes = 3.9 %}3.7.0, 3.8.0, or 3.9.0{% endif %}.
* You must have provisioned a new target {% data variables.product.product_name %} instance and restored the backup. For more information, see "[AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance)" and "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-backups-on-your-instance)."
1. SSH into the source {% data variables.product.product_name %} instance that you backed up. If your instance comprises multiple nodes, for example if high availability or geo-replication are configured, SSH into the primary node. If you use a cluster, you can SSH into any node. Replace HOSTNAME with the actual hostname of your instance. For more information about SSH access, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)."
```shell copy
ssh -p 122 admin@HOSTNAME
```
{%- ifversion ghes = 3.9 %}
1. To display a list of decryption keys, run the following command.
```shell copy
ghe-config secrets.github.encrypted-column-keying-material
```
1. Copy the output to a safe and temporary location.
1. To display a list of encryption keys, run the following command.
```shell copy
ghe-config secrets.github.encrypted-column-current-encryption-key
```
1. Copy the output to a safe and temporary location.
{%- endif %}
1. SSH into the destination {% data variables.product.product_name %} instance where you restored the backup. Replace HOSTNAME with the actual hostname of your instance.
```shell copy
ssh -p 122 admin@HOSTNAME
```
1. Enable maintenance mode. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#enabling-maintenance-mode-immediately-or-scheduling-a-maintenance-window-for-a-later-time)."
1. To verify that the destination instance is ready for configuration, run the following {% ifversion ghes = 3.9 %}commands{% endif %}. There should be no output displayed.
```shell copy
ghe-config secrets.github.encrypted-column-keying-material
{%- ifversion ghes = 3.9 %}
ghe-config secrets.github.encrypted-column-current-encryption-key
{%- endif %}
```
{%- ifversion ghes = 3.9 %}
1. To update the decryption keys on the destination instance, run the following command. Replace DECRYPTION-KEY-LIST with the output from step 1.
```shell copy
ghe-config secrets.github.encrypted-column-keying-material "DECRYPTION-KEY-LIST"
```
1. To update the encryption key on the destination instance, run the following command. Replace ENCRYPTION-KEY with the output from step 4.
```shell copy
ghe-config secrets.github.encrypted-column-current-encryption-key "ENCRYPTION-KEY"
```
{%- endif %}
1. To apply the configuration, run the following command.
```shell copy
ghe-config-apply
```
1. Wait for the configuration run to complete.
1. To ensure that the target instance's configuration contains the keys, run the following {% ifversion ghes = 3.9 %}commands{% endif %} and verify that the output matches step 1{% ifversion ghes = 3.9 %} and step 4{% endif %}.
```shell copy
ghe-config secrets.github.encrypted-column-keying-material
{%- ifversion ghes = 3.9 %}
ghe-config secrets.github.encrypted-column-current-encryption-key
{%- endif %}
```
1. Have a user sign into the destination instance. If any issues arise, contact {% data variables.contact.enterprise_support %}. For more information, see "[AUTOTITLE](/support/contacting-github-support)."
{% endif %}

1
content/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/configuring-git-large-file-storage-for-your-enterprise.md
View File

@@ -14,6 +14,7 @@ redirect_from:
- /enterprise/admin/user-management/configuring-git-large-file-storage-for-your-enterprise
- /admin/user-management/configuring-git-large-file-storage-for-your-enterprise
- /admin/user-management/managing-repositories-in-your-enterprise/configuring-git-large-file-storage-for-your-enterprise
- /admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/migrating-to-internal-repositories
versions:
ghes: '*'
type: how_to

1
content/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/index.md
View File

@@ -14,7 +14,6 @@ children:
- /viewing-user-owned-repositories-in-your-enterprise
- /accessing-user-owned-repositories-in-your-enterprise
- /configuring-git-large-file-storage-for-your-enterprise
- /migrating-to-internal-repositories
- /disabling-git-ssh-access-on-your-enterprise
- /locking-a-repository
- /restoring-a-deleted-repository

69
content/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/migrating-to-internal-repositories.md
View File

@@ -1,69 +0,0 @@
---
title: Migrating to internal repositories
intro: 'You can migrate to internal repositories to unify the innersource experience for developers using both {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %}.'
redirect_from:
- /enterprise/admin/installation/migrating-to-internal-repositories
- /enterprise/admin/user-management/migrating-to-internal-repositories
- /admin/user-management/migrating-to-internal-repositories
- /admin/user-management/managing-repositories-in-your-enterprise//migrating-to-internal-repositories
permissions: Site administrators can migrate to internal repositories.
versions:
ghes: '<3.10'
type: how_to
topics:
- Enterprise
- Privacy
- Repositories
- Security
shortTitle: Internal repository migration
---
## About internal repositories
Internal repositories are available in {% data variables.product.prodname_ghe_server %} 2.20+. {% data reusables.repositories.about-internal-repos %} For more information, see "[AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-repository-visibility)."
In future releases of {% data variables.product.prodname_ghe_server %}, we will adjust how repository visibility works so that the terms public, internal, and private have a uniform meaning for developers on {% data variables.product.prodname_ghe_server %} and {% data variables.product.prodname_ghe_cloud %}.
To prepare for these changes, if you have private mode enabled, you can run a migration on your instance to convert public repositories to internal. This migration is currently optional, to allow you to test the changes on a non-production instance. The migration will become mandatory in the future.
When you run the migration, all public repositories owned by organizations on your instance will become internal repositories. If any of those repositories have forks, the forks will become private. Private repositories will remain private.
All public repositories owned by user accounts on your instance will become private repositories. If any of those repositories have forks, the forks will also become private. The owner of each fork will be given read permissions to the fork's parent.
Anonymous Git read access will be disabled for each public repository that becomes internal or private.
If your current default visibility for repositories is public, the default will become internal. If the current default is private, the default will not change. You can change the default at any time. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#configuring-the-default-visibility-of-new-repositories-in-your-enterprise)."
The repository creation policy for the instance will change to disable public repositories and allow private and internal repositories. You can update the policy at any time. For more information, see "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise)."
If you don't have private mode enabled, the migration script will have no effect.
## Running the migration
1. Connect to the administrative shell. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)."
{% ifversion ghes %}
1. Run the migration command.
```shell
github-env bin/safe-ruby lib/github/transitions/20191210220630_convert_public_ghes_repos_to_internal.rb --verbose -w | tee -a /tmp/convert_public_ghes_repos_to_internal.log
```
{% else %}
1. Navigate to the `/data/github/current` directory.
```shell
cd /data/github/current
```
1. Run the migration command.
```shell
sudo bin/safe-ruby lib/github/transitions/20191210220630_convert_public_ghes_repos_to_internal.rb --verbose -w | tee -a /tmp/convert_public_ghes_repos_to_internal.log
```
{% endif %}
Log output will appear in the terminal and `/tmp/convert_public_ghes_repos_to_internal.log`.
## Further reading
* "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-private-mode)"

5
data/features/backup-utilities-encryption-bug.yml
View File

@@ -1,5 +0,0 @@
# Reference: ghes#6726, ghes#6731
# Encryption bug in GitHub Enterprise Server Backup Utilities
versions:
ghes: '>=3.7 <=3.9'

3
src/rest/lib/config.json
View File

@@ -6,9 +6,6 @@
"ghec": [
"2022-11-28"
],
"ghes-3.9": [
"2022-11-28"
],
"ghes-3.10": [
"2022-11-28"
],

3
src/versions/lib/enterprise-server-releases.js
View File

@@ -12,7 +12,7 @@ export const dates = JSON.parse(await fs.readFile('src/ghes-releases/lib/enterpr
export const next = '3.14'
export const nextNext = '3.15'
export const supported = ['3.13', '3.12', '3.11', '3.10', '3.9']
export const supported = ['3.13', '3.12', '3.11', '3.10']
// Edit this to `null` when it's no longer the release candidate
export const releaseCandidate = null
@@ -41,6 +41,7 @@ function isValidNext(v1, v2) {
// array and you should never need to touch the `deprecated` array
// on the line just below.
export const deprecatedWithFunctionalRedirects = [
'3.9',
'3.8',
'3.7',
'3.6',