Acerca de los problemas conocidos con las actualizaciones de GitHub Enterprise Server
GitHub es consciente de los siguientes problemas que podrían afectar a las actualizaciones de las nuevas versiones de GitHub Enterprise Server. Para obtener más información, consulta "Problemas conocidos" en las Notas de la versión de GitHub Enterprise Server.
GitHub recomienda encarecidamente realizar copias de seguridad periódicas de la configuración y los datos de tu instancia. Antes de continuar con cualquier actualización, realiza una copia de seguridad de la instancia y, a continuación, valida la copia de seguridad en un entorno de ensayo. Para más información, consulta Configuración de copias de seguridad en la instancia mediante utilidades de copia de seguridad y Configurar una instancia de preparación.
Eliminar la pausa en las actualizaciones a la versión 3.15 y posteriores
Hemos quitado la pausa en las actualizaciones a las versiones 3.15, 3.16 y 3.17. Ahora puedes actualizar a 3.15.12, 3.16.8, 3.17.5 o posterior. No se recomienda actualizar a versiones anteriores de 3.15, 3.16 o 3.17. Como paso adicional, se recomienda comprobar la capacidad del sistema antes de actualizar. Consulta Comprobación de la capacidad del sistema antes de la actualización.
Hemos ampliado la ventana de soporte técnico para las versiones 3.14, 3.15, 3.16 y 3.17. La ventana de soporte técnico para la versión 3.13 permanece sin cambios. Se ha actualizado la fecha de cierre de cada una de las versiones 3.14, 3.15, 3.16 y 3.17. Para más información, consulta Lanzamientos de GitHub Enterprise Server.
Seguiremos lanzando revisiones para 3.14, 3.15, 3.16 y 3.17 en esta ventana de soporte extendido.
El tamaño de disco raíz requerido aumentó a 400 GB.
Se ha quitado el requisito anterior de tamaño del disco raíz de 400 GB para las versiones 3.15.2 y posteriores. Este requisito se basaba en el análisis de paquetes de soporte e incidencias de soporte técnico. Algunos factores, como los registros, ejercen una presión excesiva en el disco raíz que provocó problemas del dispositivo. Después de recibir comentarios por parte de muchos clientes de que es difícil adquirir hardware nuevo, se revierte el requisito a favor de un enfoque gradual. Todavía recomendamos que los clientes, especialmente aquellos que usan topologías independientes o topologías autónomas de alta disponibilidad, actualicen el disco raíz a 400 GB. Cuando puedas actualizar el disco raíz a 400 GB, consulta las instrucciones siguientes.
Para los clientes que usan topologías de alta disponibilidad o independientes, se recomienda que las nuevas instalaciones de 3.15 o posteriores, o las actualizaciones a 3.15, utilicen el tamaño del disco raíz de al menos 400 GB. GitHub recomienda encarecidamente seguir las instrucciones de Aumentar la capacidad de almacenamiento.
Registros indescifrables
Si vas a actualizar desde GitHub Enterprise Server 3.11 o 3.12 a 3.13, o desde 3.12 a 3.14, puedes encontrarte con una incidencia con registros indescifrables debido a que faltan claves necesarias para el descifrado. La única solución es eliminar los registros indescifrables. El tipo de registros afectados por esta incidencia son registros con autenticación en dos fases, lo que significa que es posible que tenga que pedir a los usuarios que vuelvan a habilitar la autenticación en dos fases (2FA).
Antes de actualizar
Si vas a actualizar desde GitHub Enterprise Server 3.11 o 3.12 a 3.13, o desde 3.12 a 3.14, puede ejecutar el script de diagnósticos de cifrado para identificar los registros indescifrables con antelación. Este script no modificará ningún registro, pero te dará la oportunidad de comprender el impacto y planearlo.
- Descarga el script de diagnóstico de cifrado. Puedes usar un comando como
curl -L -O https://gh.io/ghes-encryption-diagnosticspara descargar el script. - Guarda el script en el directorio
/data/user/commondel dispositivo. - Sigue las instrucciones de la parte superior del script y ejecútalo en el dispositivo. Si hay registros indescifrables, se registran en
/tmp/column_encryption_records_to_be_deleted.log. Los registros registrados aquí no se pudieron descifrar porque el sistema no pudo encontrar las claves que se usaron para cifrar los registros.
Ten en cuenta que estos registros se eliminarán como parte del proceso de actualización. El script le advertirá sobre los usuarios que deberán volver a inscribirse en la autenticación en dos fases después de la actualización. Los identificadores de los usuarios afectados se registran en /tmp/column_encryption_users_to_have_2fa_disabled.log. Estos usuarios deberán volver a inscribirse en la autenticación de dos factores.
Si el script tiene incidencias inesperadas, se te pedirá que te pongas en contacto con Soporte de GitHub. Los errores relacionados con estas incidencias se registrarán en /tmp/column_encryption_unexpected_errors.log. Si está en una situación grave y no puede hacer que los usuarios vuelvan a inscribirse en 2FA, póngase en contacto con Soporte de GitHub para obtener ayuda.
El script imprimirá "Éxito: registros cifrados correctamente." si pudo encontrar las claves asociadas a los registros cifrados. Estos registros se descifrarán y conservarán durante el proceso de actualización y no requerirán tu intervención manual.
Durante la actualización
En caso de que no hayas tenido la oportunidad de ejecutar el script de diagnóstico de cifrado con antelación, hay mecanismos en el producto que te ayudarán. Las comprobaciones previas al vuelo durante el proceso de actualización detectarán registros indescifrables y los registrarán en /tmp/column_encryption_records_to_be_deleted.log. La secuencia te advertirá de los usuarios que deberán volver a habilitar la autenticación en dos fases después de la actualización. Los registros de los usuarios afectados se registran en /tmp/column_encryption_users_to_have_2fa_disabled.log.
Si se detectan registros indescifrables, se te pedirá si deseas continuar con la actualización o no. Si continúas, el proceso de actualización elimina los registros indescifrables. De lo contrario, el proceso de actualización se cerrará.
Si tienes alguna pregunta durante la actualización, puedes ponerse en contacto con Soporte de GitHub. Una vez que hayas tenido el tiempo y la oportunidad de comprender el impacto, puedes volver a activar la actualización.