Creating your new tenant
Task Description
This document explains how to make a one-time change to create your tenant - the space or partition within which you'll make most of the configuration changes to adapt CollectionSpace for your museum.
You'll perform the following steps within each of CollectionSpace's three layers:
Create the files and folders for your new tenant.
Deploy (push) these files and folders to the appropriate folders on the CollectionSpace server.
Contents
- 1 The easy way
- 2 The less-easy way
- 3 Verify Your New Tenant
- 4 Initialize Authorities and Term Lists
- 5 Next Steps
- 6 Troubleshooting
- 7 Summary
Prerequisites
Procedure for creating a new tenant
The commands listed below, which perform various steps in the configuration process, are for a Linux, Mac OS X, or other Unix-like system, and are intended to run in a Terminal shell like bash or sh. If you're using a Windows system, you can use the comparable cmd or PowerShell commands, or a tool like cygwin.
You can also use a graphical desktop interface rather than the command-line operations to perform these same steps: navigating through folders, copying folders, renaming files and folders, and so on. Also, in places where you're instructed to edit files, you're welcome to use your favorite GUI editor.
The easy way
CollectionSpace provides a tool to quickly copy the configuration of an existing tenant to create a new one.
In addition to picking the shortname and domain name as described above, you also need to select a new tenant ID,(an arbitrary integer not already used by another tenant), and existing tenant to copy. This example will show copying the core tenant, but if your collection consists of fine art of variable media, you might want to start from the fcart tenant instead.
Navigate to the directory containing the source directories for application, services and ui. Something like:
We are going to update the tenant.properties file with a few details
Now add in your values for the shortname, domain name, and tenant id of your new tenant, and the shortname of the tenant you want to clone.
Save that file and run the clone tool from the command line
Because of a bug in the latest version of the clone-tenant utility, you'll need to manually edit one of the configuration files. Open the file at application\tomcat-main\src\main\resources\<your_tenant_short_name>-tenant.xml. Ensure the value of the XML element "<tenantid>" is equal to the value you chose for your tenant ID (some number).
Now run this command:
When complete, you should see a final message that looks something like this:
BUILD SUCCESS
Total time: 45.832s
We'll now do the same process for services and ui directories
The basic custom tenant configuration files have now been created and are ready to deploy. If you want details of what the new tenant config just created, read the section below, The less-easy way. Otherwise, you can skip ahead to the Deploy section below
If you've previously deployed and started your CollectionSpace instance, then you'll need to also run the following command to create the necessary AuthN/AuthZ information for your new tenant.
You're now ready to launch/start CollectionSpace. Once started, you can login to your new tenant with a URL that looks something like this:
The less-easy way
Make a folder/directory to hold the source code for all three CollectionSpace layers: Services, Application, and UI
Make a new folder to contain the CollectionSpace source code for all three CollectionSpace layers. You might name it something like
cspaceorcollectionspaceor evencspace-source, for example.
User Interface (UI) layer Changes
Create and modify the UI layer files and folders for your new tenant
Change directories into the folder you previously created to hold the CollectionSpace source code.
Check out the UI source code directly into that folder.
Make sure that the folder created by the checkout process is named
ui(If it isn't, rename that folder toui)Change directories into that newly-checked out
uifolder.
For instance, at a Terminal prompt in a Linux, Mac OS X, or other Unix-like system, you could enter:Copy the entire
src/main/webapp/tenants/corefolder, with all of its contents, to a new folder named for your museum. This new folder should reside directly alongside thecorefolder. (That is, both folders should be contained within the same parent folder.)
For instance, at a Terminal prompt in a Linux, Mac OS X, or other Unix-like system, you could enter:Open the file
src/main/webapp/tenants/mymuseum/bundle/core-messages.properties-overlayin a text editor.Using your editor's global search and replace tool, globally replace, using case-sensitive replacement, every instance of
corewith demo.
Deploy (push) your new tenant to the CollectionSpace server
Directly within the folder in which you've checked out the UI source code (i.e. not in a sub-folder), at a Terminal or command prompt, enter:
This will package up your new tenant, along with other UI-related files, into a cspace-ui.war file. That file will then be deployed (pushed) to the CollectionSpace server, in the location $CSPACE_JEESERVER_HOME/webapps.
If you were to peek inside that WAR file (for instance, via the command jar tvf $CSPACE_JEESERVER_HOME/webapps/cspace-ui.war), among the many files listed there you'd see your new tenant at tenants/{mymuseum}, where mymuseum is the actual short name of your museum.
Application layer
Create and modify the Application layer files and folders for your new tenant
Change directories into the folder you previously created to hold the CollectionSpace source code.
Check out the Application source code directly into that folder.
Make sure that the folder created by the checkout process is named
application(If it isn't, rename that folder toapplication)Change directories into that newly-checked out
applicationfolder.
For instance, at a Terminal prompt in a Linux, Mac OS X, or other Unix-like system, you could enter:Copy the file
tomcat-main/src/main/resources/core-tenant.xmlto a new file renamed with your museum's short name.
For instance, at a Terminal prompt in a Linux, Mac OS X, or other Unix-like system, you could enter:Open the file
tomcat-main/src/main/resources/{mymuseum}-tenant.xmlin a text editor.Using your editor's global search and replace tool, globally replace, using case-sensitive replacement, every instance of
corewithdemo.
Copy ("clone") the entire tenant folder for the
coretenant,tomcat-main/src/main/resources/tenants/corewith all of its contents, to a new folder in the same location, renamed to your museum's short name. This new folder should reside directly alongside thecorefolder. (That is, both folders should be contained within the same parent folder.)
For instance, at a Terminal prompt in a Linux, Mac OS X, or other Unix-like system, you could enter:Open the file
tomcat-main/src/main/resources/tenants/demo/settings.xmlin a text editor.Using your editor's global search and replace tool, replace every instance of
core.collectionspace.orgwith the Internet domain name of your museum; for examplewalkerart.orgorucjeps.berkeley.eduAfter making this change, here's an excerpt from what part of that file should now look like if, for example, your museum's Internet domain name weremymuseum.org:Using your editor's global search and replace tool, globally replace, using case-sensitive replacement:
Every instance of
corewithdemoEvery instance of
CorewithDemo
After making this change, here's an excerpt from what part of that file should now look like:
Change the tenant ID (the value of the
<tenant>element) from its current value to a new value, one not used by any other tenant in your CollectionSpace system. In the following example, the tenant ID for thedemotenant has been changed from its default value of1to a new value of 5:Make the identical change, in this example from
1to 5, to the second instance of the tenant ID in that file (the value of the<id>element inside the<service>...<tenant>section):
Recommended: If you would like your museum's data to be stored in a separate database, rather than intermingled with that of other museum tenants in a common database, add a
<name>element to the<repository>section, with its value set to your desired name for that separate database. (The value of that element must be a valid PostgreSQL database name; see the PostgreSQL documentation on valid identifiers for the current naming rules.)
See Storing your museum's data in its own database for more information on this option.
In the example below, a<name>element was added, with a value ofmymuseum_domain. This will result in the creation of a database namedmymuseum_domain,which will be used to store data for themymuseumtenant:Save your modified file,
tomcat-main/src/main/resources/tenants/demo/settings.xml