Clonando sitios de Totara de una copia de seguridad de la base de datos

Al configurar un nuevo sitio, es posible que desees comenzar con alguna configuración predeterminada. Una forma de lograr esto es clonar la base de datos y los datos del sitio de un sitio existente. Cuando se utiliza este método, a menudo todo parece funcionar bien, pero hay algunos problemas sutiles causados por la clonación que pueden causar problemas significativos en un sitio de producción.

Por lo tanto, recomendamos encarecidamente realizar una instalación nueva para cualquier sitio que se utilizará en la producción. Consulta a continuación para obtener más información sobre nuestro enfoque recomendado y las cosas a considerar si estás clonando desde una copia de seguridad.

Importancia de restablecer el identificador del sitio

Un problema significativo que puede ocurrir cuando un sitio es clonado de una copia de seguridad de la base de datos es que puedes terminar con el mismo identificador de sitio en varios sitios. El identificador del sitio se almacena en la configuración $CFG→siteidentifier y se requiere que sea un valor único entre los sitios. Muchas áreas de código dependen de la singularidad de esta variable. Si restauras un nuevo sitio desde una copia de seguridad por cualquier motivo que no sea mover el sitio a una nueva URL, debes desestablecer la variable de configuración del identificador del sitio. El sistema generará automáticamente un nuevo identificador único cuando sea necesario.

A continuación se presentan algunos problemas potenciales que hemos identificado que podrían ocurrir en sitios que utilizan los mismos identificadores de sitio. Esta no es una lista exhaustiva, solo algunos ejemplos que destacan los problemas.

Caché

El sistema de caché incorporado utiliza el identificador del sitio para generar una clave única (ver get_cache_identifier() en /cache/classes/definition.php). Si dos sitios con el mismo identificador están utilizando el mismo almacenamiento en caché, existe la posibilidad de que los datos almacenados en caché de un sitio se transfieran incorrectamente al otro sitio. Esto podría incluir información confidencial o información crítica del sistema, como datos de configuración. El uso incorrecto de los datos en caché de otro sitio tiene el potencial de dañar críticamente los sitios; por ejemplo, si los datos de la configuración en caché o de la estructura de la tabla de la base de datos de un sitio se utilizan por código en otro.

Copia de seguridad y restauración

La copia de seguridad y la restauración utilizan el identificador del sitio para determinar si una copia de seguridad se está restaurando en el mismo sitio que se generó o no. El sistema se comporta de manera diferente dependiendo de si el origen y el destino coinciden o no. Por ejemplo, en lugar de crear un nuevo usuario, el sistema puede asignar datos restaurados a un usuario existente si cree que el usuario coincide (ver comentarios arriba precheck_user() en /util/dbops/restore_dbops.class.php ). Si bien existen verificaciones adicionales (la ID de usuario y el nombre de usuario deben coincidir), aún existe la posibilidad de una asignación incorrecta de datos si se restaura una copia de seguridad de un sitio en un sitio diferente cuando se comparte el mismo identificador de sitio, particularmente si los usuarios se clonan como parte de la configuración del nuevo sitio.

LTI

LTI utiliza el identificador del sitio para generar tokens secretos que se utilizan para autenticar el acceso a los paquetes LTI (ver generate_cartridge_token() en /enrol/lti/classes/helper.php). Teóricamente, un usuario con acceso a un sitio podría autenticarse en un curso en cualquier otro sitio que comparta el mismo identificador del sitio, si hay un curso que comparta la misma ID de curso que el curso al que tienen acceso en su sitio. Esto representaría un problema de seguridad significativo.

Enfoque recomendado para crear instancias de sitio

Nuestro enfoque recomendado para configurar un nuevo sitio sería el siguiente:

• Crear un nuevo sitio desde cero con una base de datos vacía y una raíz de datos
• Instalar el sitio utilizando el procedimiento de instalación normal (CLI o a través de la web)
• Considera crear un plugin de sabor (consulta los comentarios en /totara/flavour/classes/definition.php para ver cómo crear un sabor) para establecer la configuración inicial y los ajustes por defecto
• Crear un plugin local y usar scripts db/install.php o CLI para crear cualquier contenido por defecto

Consideraciones para restaurar desde copias de seguridad de la base de datos

Si bien recomendamos enfáticamente no hacer esto por los motivos descritos anteriormente, y no podemos proporcionar soporte para ningún problema que surja debido a los sitios configurados de esta manera, si eliges crear un sitio de esta manera, te recomendamos que consideres cuidadosamente lo siguiente:

• Debe desestablecer la configuración del identificador del sitio en el nuevo sitio, a menos que:
  • Estás moviendo el sitio a una nueva URL (en cuyo caso debería permanecer igual).
  • Está copiando una base de datos de producción a un servidor de prueba o de puesta a disposición para fines de prueba (debe estar bien siempre que su servidor de prueba esté correctamente aislado de la instancia de producción).
• Tu base de datos puede incluir referencias a la URL del sitio, que probablemente querrás reemplazar. Hay un script que hace esto (/admin/cli/replace.php), pero no respaldamos su uso y no podemos garantizar que funcionará correctamente.
• Debe truncar cualquier registro del sitio inmediatamente después de restaurar el sitio.
• Recomendamos mantener la cantidad de contenido en el sitio con una copia de seguridad mínima absoluta. Cuanto menos contenido haya, menos posibilidades habrá de que haya un problema.

Qué hacer si tienes sitios existentes que comparten un identificador de sitio

Te recomendamos que, si es posible, desactives el identificador del sitio y generes uno nuevo llamando a la función moodlelib.php get_site_identifier(). Sin embargo, esto deberá evaluarse caso por caso teniendo en cuenta los siguientes posibles impactos:

• Asegúrate de tener una copia de seguridad completa de tu base de datos y datos del sitio antes de desestablecer el identificador del sitio.
• Las cachés serán invalidadas. Borra tu caché inmediatamente después de desconfigurar el identificador del sitio.
• Ten en cuenta que cualquier copia de seguridad generada en el sitio que restauras en el mismo sitio ahora tratará al sitio como si fuera un sitio diferente en lugar del mismo.
• Revisa cuidadosamente el código de cualquier plugin de terceros para identificar cualquier dependencia en el identificador del sitio y determinar cómo se comportarán.