Skip to main content
  1. Install Curator using Linux installer like usual.
  2. You can make a new directory called centraldispatch at /var/www and move the contents of the webroot (/var/www/html) there or you can leave it as is. The newly deployed instances will be located at /var/www/instance-name while the main Central Dispatch site remains at /var/www/html or /var/www/centraldispatch. The rest of the guide will assume /var/www/html so change all of the commands to the correct path if you chose /var/www/centraldispatch.
  3. Set up SSL for this initial instance. This blog by the great and powerful Orr will get you most of the way there. NOTE: Ubuntu systems are slightly different.
  4. There should already be a default conf file that has an IncludeOptional line that points to a directory where additional vhost conf files can go. Make sure you know where the newly added vhost conf files should go:
    • Ubuntu:
      • Default conf: etc/apache2/apache2.conf
      • Includes vhost conf files: etc/apache2/sites-enabled/*.conf
      • Ubuntu is a little different and actually stages the conf files here before being enabled: /etc/apache2/sites-available/*.conf
    • Everything else:
      • Default conf: /etc/httpd/conf/httpd.conf
      • Includes vhost conf files: /etc/httpd/conf.d/*.conf
  5. Create database user using the worker_database_user.sql example script at /var/www/html/plugins/interworks/centraldispatch/workers directory. Tweak the password if you’d like before executing.
    • Run the sql file:
    • Enter root password
    • Test if the new user is there: mysql -u worker -p
    • Enter worker password
  6. Create directory /var/www/archives
  7. Set up worker script
    1. Copy php_worker.example.php script to php_worker.php in the /var/www/html/plugins/interworks/centraldispatch/workers directory:
    2. Copy vhost.template.example.conf to vhost.template.conf in the same directory.
    3. Make sure apache user owns everything:
    4. Tweak paths as needed in php_worker.php
      1. DB_ENV_DISPATCHER uses details from step 5 above.
      2. DB_ENV_INSTANCE uses the root database details to be able to provision users as needed. Can set up dispatcher user with these permissions if you don’t want to use the root account.
      3. Modify vhost section:
        1. Uncomment directory and modify as needed to where the vhost conf files should go from step 4.
        2. Uncomment template for /var/www/html/plugins/interworks/centraldispatch/workers/vhost.template.conf.
      4. Modify worker section:
        1. Uncomment source_directory for /var/www/html.
        2. Uncomment archive_directory for /var/www/archives.
      5. Modify $DEFAULT_BACKEND_EMAIL as needed.
      6. Modify $LINUX_APACHE_RESTART to the relevant apache restart command for your distro.
      7. Modify $LINUX_APACHE_USER to the relevant apache user for your distro.
    5. Tweak vhost template as needed in workers directory
      1. Comment out the #apache 2.2 lines (lines 22-23) and uncomment out the #apache 2.4 lines unless using Apache 2.2.
      2. Update SSLCertificateChainFile, SSLCertificateFile, and SSLCertificateKeyFile as needed.
    6. Schedule root to run worker with the following command. Feel free to change the frequency (this one is every 15 minutes). Also, make sure to change $APACHEUSER to the relevant apache user in the chown command (this makes sure the application owns all the files even though root is making everything).
  8. Restart apache
  9. In the Central Dispatch Curator portal’s backend, register the workers with the dispatcher at Backend > Settings > Central Dispatch > Central Dispatch Settings. Probably with these settings:
    1. Host URL: localhost
    2. Worker name: localhost (or use something more descriptive)
    3. Install Path: /var/www
  10. Attempt to deploy a new managed instance at Backend > Central Dispatch > Managed Instances.

​
Configuring Managed Instances After Deployment

Each managed instance is a full, standalone Curator install with its own web root, its own database, and its own settings. Integrations such as Tableau are configured on the instance itself, not on the Central Dispatch controller. To configure an instance, browse to that instance’s own backend URL — for example https://instance-name.example.com/backend — and set up its Tableau connection there.
Managed instances do not share settings. Because every instance has its own isolated database, the Tableau connection credentials you configure on one instance have no effect on any other instance. Always confirm the URL in your browser’s address bar before saving so you know which instance you are editing.
When deploying several instances in quick succession, follow this workflow to avoid configuring the wrong instance:
  1. Wait for the worker to finish provisioning before configuring an instance. In the Managed Instances list, an instance that is still provisioning shows a pending Status such as pending deployment; once the worker completes, the Status column reflects the live instance instead. The worker runs on the schedule you set in step 7 (every 15 minutes in the example cron), so a newly requested instance may not be ready immediately.
  2. Open each instance’s backend URL in its own browser tab, and check the address bar before saving, so you can be certain which instance you are configuring.
  3. After saving an instance’s Tableau settings, return to Backend > Central Dispatch > Managed Instances. The list includes a Tableau Server column that reports the Tableau server URL each instance is connected to, letting you confirm from the controller that every instance has the settings you expect.

​
Manual Back Out of Deployment

In case of a failure during a deployment, Central Dispatch is not yet able to automatically back out the deployment to try again. You can determine the nature of the failure by visiting the Managed Instance record in the backend of the Central Dispatch portal and scrolling to the bottom of the page. There will be an error field that will show any issues the worker had during the deployment. To back out a deployment, it’s important to determine which step it failed at so you’ll know which of the following steps you’ll need to take to back it out. They are in reverse order of the deployment, so you can skip steps if the deployment didn’t make it that far. When in doubt, just perform all of the steps.
  1. Remove cron job with the name of this managed instance by using sudo -u <apache user> crontab -e to edit. Note: This will use VI as the default editor in case you need to look up how to edit the file.
  2. If using Ubuntu, disable the vhost entry by running sudo a2dissite <managed instance vhost record without .conf>
  3. Remove the vhost record specific to this managed instance in the vhosts directory (see step 4 above to determine location). The command will be similar to sudo rm /etc/apache2/sites-available/<managed instance vhost record>
  4. Remove site-specific SSL/TLS certificate, key, and (optional) chain certificate, if the managed instance supplied them. These should be in the /etc/apache2/certs/ directory. The commands will be similar to these two commands below:
  5. Remove the portal code for the managed instance in the /var/www/ directory. The command will be similar to sudo rm -Rf /var/www/<managed instance web root directory name>
  6. Drop the database specific to the managed instance by using mysql -u root -p and the root database credentials (see /var/www/info.txt). The SQL statement to drop the database would be: DROP DATABASE '<database name>';
  7. Delete the database user specific to the managed instance by using mysql -u root -p and the root database credentials (see /var/www/info.txt). The SQL statement to drop the database would be: