Vidicore
The VidiCore integration in Helmut4 allows VidiCore users to automate their media management in the cloud. It gives you full control over API-driven processes, enabling the creation of powerful workflows.
Helmut4’s Streamdesigner offers several dedicated VidiCore nodes, which can be used to interact with a native VidiCore system. By including these nodes in a stream, you can create workflows that handle collections, files, items, libraries, and metadata efficiently.
Note Each node needs the URL of the corresponding VidiCore system. To simplify this, it's recommended to use variables and wildcards in the relevant fields. To connect to the VidiCore system and obtain the required token for proper authentication, make sure to include the "VidiCore Get Token" node at the start of all VidiCore streams.
The relative file path is different from the path used by the locally mounted remote storage. It refers to the external drive's view and points to a specific location within that storage.
SSL Certificate Setup for On-Premise Vidicore Environment
When using Helmut4 with an on-premise Vidispine system, it is crucial to have a dedicated Java cacerts keystore if communication occurs over HTTPS.
This is because Helmut4 validates SSL certificates when communicating with Vidispine. However, locally hosted systems are not verified by public root certificate authorities. As a result, Helmut4’s internal certificate store will block the communication due to failed authentication if a proper SSL certificate is not in place.
Step 1: Creating a cacerts Keystore
To set up the required certificates, follow these steps:
1.1 Generating Certificates
You can generate the necessary certificates using either Java’s keytool utility or OpenSSL:
Using Java keytool: Java’s keytool utility can be used to manage certificates and create the cacerts keystore.
After generating or obtaining the certificates, you can import them into the cacerts keystore using:
Ensure the correct path to Java's cacerts is used, typically located at $JAVA_HOME/lib/security/cacerts. The default password for the keystore is changeit.
Using OpenSSL: You can also use OpenSSL to generate or convert certificates and then import them into the Java keystore using keytool.
1.2 Adding Certificates to the System Trust Store
In addition to adding the certificates to the Java keystore, you should also add them to the system-wide CA trust store to ensure HTTPS communication works properly across the system:
Navigate to the /usr/local/share/ca-certificates/ directory on your server.
Copy or create the root and intermediate certificates in .crt format. To create these files, use a text editor such as nano or vim. For example, use the following command to create the root certificate:
Then paste the certificate content between the following markers:
Repeat this process for intermediate certificates if required.
Once the certificates are added, run the following command to update the system’s trust store located at /etc/ssl/certs:
Step 2: Mounting cacerts into Containers
After the cacerts keystore is set up, it needs to be mounted into the relevant containers. If you are working in a cluster environment, ensure the cacerts file is present on every server in the cluster.
2.1 Defining the cacerts Path in Containers
In your stack configuration (via Portainer or Docker Compose), define the path to the cacerts file on the host server and mount it into the containers. For each container, such as fx, io, co, hk, users, and streams, add the following line in the volumes section:
This ensures that each container uses the correct cacerts file for SSL communication.
Step 3: Keeping the cacerts File in Sync
In case of future certificate updates or changes, ensure that the cacerts file is updated on all relevant servers and mounted correctly across all containers in the cluster. This helps maintain consistent and secure SSL communication.
Last updated