The concept should also work with censhare Web and AWS S3 as long as no assets with storage items (especially InDesign templates, modules configuration assets, workspaces, transformations, widgets, etc.) are (manually) deleted on the production system. Workspaces can be disabled instead of deleted.


Mount RO live assets filesystems on a test environment

In some cases, it is required to have the production assets also on a test server to build up a proper environment. With the rising amount of assets, it becomes more and more difficult to manage the data twice. Therefore, you may want to mount the asset volumes from the live system to the test environment. For security reasons, it is recommended to mount the live asset volumes read-only on the test side.

In the following example, we will mount the live asset volumes through NFS. The /etc/fstab may look like below:

censharefs:/data/assets /opt/assets-ro nfs ro,soft,bg,tcp,nolock,actimeo=3,timeo=100
censharefs:/data/assets_2 /opt/assets_2-ro nfs ro,soft,bg,tcp,nolock,actimeo=3,timeo=100
XML

If you're not sure which assets filesystems you'll need, have a look into the filesystem configuration and/or within the database (you may also consult the responsible project manager):

cat ~/cscs/app/services/filesystem/config.<CSS_ID>.xml
...
<filesystem name="assets" type="appledouble" url-creator="storage-sequence" url="file:work/assets/" usage="assets" lost-found-dir="file:lost+found/"/>
<filesystem name="assets2" type="appledouble" url-creator="storage-sequence" url="file:work/assets_2/" usage="assets" lost-found-dir="file:lost+found/"/>
...
CODE

Keep in mind that an asset filesystem usage clause does not have to be "assets". Search within the database for filesystems:

SQL> col name format a30 heading "name"  
SQL> select name, usage from filesystem_def where usage='assets';
name		   USAGE
------------- --------
assets		   assets
assets2		   assets
...
XML

So, let's assume that these two are the only needed filesystems.

Now, configure, within the censhare Admin Client, a dummy domain for every filesystem. Add a description! As an example, if you have a domain called root.print., you will also need a domain called root.ro.print..

You will need, of course, the assets and assets2 filesystems, too. Existing assets will be elected from the -ro filesystems, while storing new assets will take place into the usual ones.

Link the ro-filesystems into the work directory and adapt the filesystem configuration keeping the existing ones:

cd ~work && ln -s /opt/assets-ro
ln -s /opt/assets_2-ro

vi ~/cscs/app/services/filesystem/config.<CSS_ID>.xml

# the config should now look just about in the following way

<filesystem name="assets" type="appledouble" url-creator="storage-sequence" url="file:work/assets/" usage="assets" lost-found-dir="file:lost+found/"/>
<filesystem name="assets2" type="appledouble" url-creator="storage-sequence" url="file:work/assets_2/" usage="assets" lost-found-dir="file:lost+found/"/>

<!-- ro filesystems -->
<filesystem name="assets-ro" type="appledouble" url-creator="storage-sequence" url="file:work/assets-ro/" usage="assets" lost-found-dir="file:lost+found/"/>
<filesystem name="assets2-ro" type="appledouble" url-creator="storage-sequence" url="file:work/assets_2-ro/" usage="assets" lost-found-dir="file:lost+found/"/>
CODE

We assume that the database clone is already in place. So, next, we need to add a dummy domain and the filesystem within the master data. Then, change the storage items within the database:

SQL> insert into domain (pathid, parent, shortname, name, name_de, sorting, enabled, tcn) values ('root.dummy.', 'root.', 'dummy', 'dummy', 'dummy', '8000', '1', '0');
SQL> insert into filesystem_def (name, description, description_de, domain, domain2, usage, master, color, enabled, tcn) values ('assets-ro', 'assets-ro', 'assets-ro', 'root.dummy.', 'root.', 'assets', null, null, '1', '0');
-- now update the filesystem
SQL> alter index storage_item_idx3 unusable;
SQL> update storage_item set filesys_name = 'assets-ro' where filesys_name = 'assets';
SQL> update storage_item set filesys_name = 'assets2-ro' where filesys_name = 'assets2';
SQL> alter index storage_item_idx3 rebuild;
CODE

You need the assets and assets2 filesystems, too. Existing assets will be elected from the -ro filesystems, while storing new assets will take place into the usual ones.

Rebuild CDB on the test environment after the SQL update statement. \\
Und Deaktivieren der censhare file replication auf dem Testsystem
XML

Details

The censhare system stores the files of an asset using its domains. The "mapping" is done through the filesystem_def table contents. To store files, the asset manager tries to find the best (most specific / longest) matching file system by comparing the asset domain with all filesystem_def domain/domain2 entries.

For reading asset files, the domain of an asset is completely ignored. The censhare system just uses the filesys_name, relpath - or if archived the archivesys_name and archive_id (typically again = relpath) - of a storage item.