August 26, 2022
The topic discussed here is not covered by Curator support and is not recommended as it is difficult to predict all the ways this may cause problems as the platform evolves. This is only a guide provided as an attempt to make your life easier if you need to use a scripted deployment procedure for Curator due to internal IT policies. By taking the approach discussed below, you are assuming the burden of setting it up to work in your environment, maintaining it as needed and fixing issues as they arise. You’ve been warned. Good luck!
The Curator team continues to strive toward making the upgrade process as smooth and reliable as possible. We’ve created one-click upgrade button, manual upgrade options for air-gapped installations and we continue to adjust as new flaws are found. With that said, sometimes IT policies require special upgrade procedures that must bypass the standard upgrade options. While these custom procedures aren’t supported by the Curator team, we can make recommendations on the most reliable way to carry out those procedures so they mesh as much as possible with Curator’s expectations.
One pattern we’ve seen a few different customers implement automates the deployment of a new web server with a new installation of Curator on top by using a scripting framework – think things like Docker, Cloud Formation, Ansible and similar tools. While this approach introduces complications around the upgrade process, there are some best practices that can make it more successful. If you’re looking to implement one of these scripted deployment-based approaches, this will outline the gist of how you’ll want to go about it and identify some gotchas you may want to handle.
It’s one thing to script the creation of a new Curator portal; it’s a totally different beast to script the fresh deployment of a cloned Curator portal. The general flow you’ll want to take is:
While redeploying a Curator portal, you may need to specify the database connection details, persistent storage location, license key or other advanced configuration. The Linux installer includes various arguments to set these during the install. See the section on “Custom Setup” at this post for more details.
Curators normal upgrade procedure is a two-part process: Upgrade the code and modify the database as needed. Without both steps in whatever process you use, Curator will behave more like a drunken robot spewing vile error messages at you. The following CLI artisan command from Curator’s web root directory should handle the database modifications if you’ve got the code updates covered.
Linux (Redhat-like installations):
sudo -u apache php artisan portal:migrate
Linux (Ubuntu-like installations):
sudo -u www-data php artisan portal:migrate
php.exe artisan portal:migrate
One area of a Curator installation that isn’t touched by the normal upgrade procedure but is overwritten by a full backup restoration is the <web root>
Anyhoo, the two most important ones for this topic are the database connection details and the encryption key used for encrypting sensitive data at rest in Curator’s database. The connection details are set during installation and changing them after the fact is an involved process. The encryption key is auto-generated during the installation process. If you’re restoring to a system that uses different database connection details, you’ll need to modify the backup to include those details prior to restoration (process documented below). However, if you’re restoring the previously encrypted data from a different installation, you’ll need to retain the encryption key that was used to encrypt the data (set in
Usually, the new deployment will happen before the previous one is decommissioned. This means that the new deployment is likely using a temporary URL. Curator includes a few different areas where the URL matters:
Curator installers add a cron/scheduled task to run its process queue once per minute. Be sure whatever redeployment procedure you use sets up this cron (Linux) or scheduled task (Windows) to run as the web server’s user (apache, www-data or SYSTEM) and, specifically with Windows, to run every minute whether anyone is logged into the server or not. It’s not always immediately apparent when this is missed, but it will cause issues over time.
Curator stores the database connection details in <web root>
The zip archive of the web root within a full backup also contains those same connection details. If the database connection differs from the system the backup originated from to the system being restored over, you'll need to perform these steps prior to restoring: