Kloon Totara-sites van een databasekopie

Bij het opzetten van een nieuwe site wil je misschien beginnen met een standaard configuratie en -instelling. Eén manier om dit te bereiken is door de database en sitegegevens van een bestaande site te klonen. Wanneer deze methode wordt gebruikt, lijkt alles vaak goed te werken, maar er zijn enkele subtiele problemen die worden veroorzaakt door klonen, wat aanzienlijke problemen op een productiesite kan veroorzaken.

Daarom raden we ten zeerste aan om een nieuwe installatie uit te voeren voor elke site die in de productie zal worden gebruikt. Zie hieronder voor meer informatie over onze aanbevolen aanpak en dingen om rekening mee te houden als je kloont vanuit een back-up.

Belang van het resetten van de site-ID

Een belangrijk probleem dat kan optreden wanneer een site wordt gekloond vanuit een databaseback-up, is dat je dezelfde site-ID op meerdere sites kunt krijgen. De site-ID wordt bewaard in de $CFG→siteidentifier config-instelling en moet een unieke waarde zijn op alle sites. Veel codegebieden zijn afhankelijk van de uniekheid van deze variabele. Als je een nieuwe site terugzet van een back-up om een andere reden dan het verplaatsen van de site naar een nieuwe URL, dan moet je de site-identifier configuratievariabele uitschakelen. Het systeem zal automatisch een nieuwe unieke identificatie genereren wanneer het de volgende keer nodig is.

Hieronder staan enkele mogelijke problemen die we hebben geïdentificeerd en die kunnen voorkomen op sites die dezelfde site-ID's gebruiken. Dit is geen uitputtende lijst, slechts enkele voorbeelden die de problemen onder de aandacht brengen.

Caching

Het ingebouwde cachingsysteem maakt gebruik van de site-ID om een unieke sleutel te genereren (zie get_cache_identifier() in /cache/classes/definition.php). Als twee sites met dezelfde id gebruik maken van dezelfde cache-opslag, bestaat de mogelijkheid dat de gecached gegevens van de ene site foutief worden doorgegeven aan de andere site. Dit kan gevoelige informatie zijn, of systeemkritieke informatie zoals configuratiegegevens. Fout gebruik van gecached gegevens van een andere site kan de site(s) kritisch beschadigen - bijvoorbeeld als gecached configuratie of databasetabel structuurgegevens van de ene site gebruikt worden door code op een andere.

Back-up en terugzetten

Back-up en terugzetten gebruikt de site-ID om te bepalen of een back-up teruggezet wordt op dezelfde site als waarop die gegenereerd is of niet. Het systeem gedraagt zich anders, afhankelijk van of de bron en bestemming overeenkomen of niet. In plaats van bijvoorbeeld een nieuwe gebruiker aan te maken, kan het systeem herstelde gegevens toewijzen aan een bestaande gebruiker als het van mening is dat de gebruiker overeenkomt (zie opmerkingen hierboven precheck_user() in /util/dbops/restore_dbops.class.php ). Hoewel er extra controles zijn (de gebruikers ID en gebruikersnaam moeten beide overeenkomen), bestaat er nog steeds een kans op een foute toewijzing van gegevens als een back-up van één site wordt hersteld op een andere site wanneer ze dezelfde site-ID delen, vooral als gebruikers worden gekloond als onderdeel van de installatie van de nieuwe site.

LTI

LTI maakt gebruik van de site-ID om geheime tokens te genereren die worden gebruikt om de toegang tot LTI-pakketten te verifiëren (zie generate_cartridge_token() in /enrol/lti/classes/helper.php). In theorie kan een gebruiker met toegang tot één site zich authenticeren voor een cursus op een andere site die dezelfde site-ID deelt, als er een cursus is die dezelfde cursus ID deelt als de cursus waartoe ze toegang hebben op hun site. Dit zou een belangrijk beveiligingsprobleem zijn.

Aanbevolen aanpak voor het maken van site-exemplaren

Onze aanbevolen aanpak voor het opzetten van een nieuwe site zou als volgt zijn:

• Maak een nieuwe site vanaf nul met een lege database en data root
• Installeer de site volgens de normale installatieprocedure (CLI of via het internet)
• Overweeg het maken van een smaakplugin (zie opmerkingen in /totara/flavour/classes/definition.php voor het maken van een smaak) om de initiële configuratie en standaardinstellingen in te stellen
• Maak een lokale plugin en gebruik db/install.php of CLI-scripts om standaardinhoud te maken

Overwegingen bij het terugzetten van databasekopieën

Hoewel we dit ten zeerste afraden om de hierboven beschreven redenen en geen ondersteuning kunnen bieden voor problemen die zich voordoen door sites die op deze manier zijn opgezet, raden we je aan om, als je ervoor kiest om op deze manier een site te maken, het volgende zorgvuldig te overwegen:

• Je moet de configuratie-instelling van de site-ID op de nieuwe site uitschakelen, tenzij:
  • Je verplaatst de site naar een nieuwe URL (in dat geval moet die hetzelfde blijven).
  • Je kopieert een productiedatabank naar een test- of testserver voor testdoeleinden (je moet in orde zijn, zolang je testserver goed geïsoleerd is van de productie-instantie).
• Je databank kan verwijzingen bevatten naar de URL van de site, die je waarschijnlijk wil vervangen. Er is een script dat dit doet (/admin/cli/replace.php), maar we ondersteunen het gebruik ervan niet en kunnen geen garanties geven dat het correct zal werken.
• Je moet alle site logs onmiddellijk inkorten nadat je de site hersteld hebt.
• We raden aan om de hoeveelheid inhoud op de site waarvan een back-up wordt gemaakt tot een absoluut minimum te beperken. Hoe minder inhoud er is, hoe kleiner de kans dat er een probleem is.

Wat moet je doen als je bestaande sites hebt die een site-ID delen?

We raden je aan om, indien mogelijk, de site-ID uit te schakelen en een nieuwe te genereren door de moodlelib.php-functie get_site_identifier() aan te roepen. Dit moet echter per geval worden beoordeeld, rekening houdend met de volgende mogelijke gevolgen:

• Zorg ervoor dat je een volledige kopie hebt van je databank en sitegegevens voordat je de site-ID deactiveert.
• Caches worden ongeldig gemaakt. Wis je cache onmiddellijk nadat je de site-ID hebt uitgeschakeld.
• Houd er rekening mee dat alle back-ups die je op de site terugzet, de site nu behandelen alsof het een andere site is in plaats van dezelfde.
• Controleer zorgvuldig de code van eventuele plugins van derden om eventuele afhankelijkheden van de site-ID te identificeren en te bepalen hoe ze zich zullen gedragen.