Conductor Documentation

WRC-CFS Deployment on WRCP

Introduction

CFS (Conductor File Service) provides file access and retrieval, as well as WRCP ISO customization services for WRC workflows.

This page explains how to deploy CFS within WRCP. CFS utilizes Ceph for persistent storage, and administrators can configure multiple replicas (more than one) across worker nodes to ensure high availability.

Installation Procedure

Create an override-values.yaml file as shown in the following example:

# Default values for cfs services.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
nameOverride: "cfsapp"
fullnameOverride: "cfsapp"
 
global:
  namespace: cfs
 
cfsapp:
  image:
    repository: xx.xx.xx.xx/conductor/conductor-file-service
    tag: WRC_latest-250102_1651Z
  logginglevel: "DEBUG"
  FILE_SERVER_URLROOT: "http://xx.xx.xx.xx:30220"
  FILE_SERVER_PATHROOT: "/cfs-data"
 
cfsfileserver:
  image:
    repository: xx.xx.xx.xx/conductor/nginxinc/nginx-unprivileged
    tag: 1.25.4
 
volume:
  accessModes: ReadWriteOnce
 
persistentVolume:
  size: 20Gi
  storageClass: cephfs
 
certificates:
  enabled: false

Installation Command:

You have the following installation options:

If you choose to not to configure certificates, run following:

helm install -n cfs cfsapp -f cfs-override-values.yaml <cfs-charts.tgz>

If choose to configure certificates, extract the helm chart, create certificates directory under resources, follow Certifications configuration instructions, and then run following:

helm install -n cfs cfsapp . -f cfs-override-values.yaml

Uninstall Command:

To uninstall, enter:

helm uninstall cfsapp -n cfs

Upload a file:

Login to the WRCP cluster that hosts cfs and run the following commands:

kubectl exec -it <cfsapp pod> /bin/bash  -n cfs -c cfsfileserver
 
Copy file to cfsfileserver:
kubectl cp test.yaml <cfsapp pod>:/cfs-data -n cfs -c cfsfileserver

File Access:

http://xx.xx.xx.xx:30220/

ISO customization Access:

http://xx.xx.xx.xx:30215/

Example: ISO customization access

Certificate Configuration (Optional)

Create a directory to hold the CFS certificates on the WRCP host that will host CFS.

  1. After extracting the helm chart, create the certificates directory under resources:
mkdir -p resources/certificates

Generate Certificates (if using selfSigned certs)

  1. Generate Certificates on CFS WRCP host:
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=SelfSignedRootCA"
  1. Generate the server side of certificates. On the CFS WRCP host, enter:
openssl genrsa -out server.key 2048
 
openssl req -newkey rsa:2048 -nodes \
  -subj "/CN=<ip address: xx.xx.xx.xx>" \
  -addext "subjectAltName=IP:<ip address: xx.xx.xx.xx>" \
  -keyout server.key \
  -out server.csr
 
 
openssl x509 -req \
  -in server.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -days 3650 \
  -sha256 \
  -out server.crt \
  -extfile <(echo "subjectAltName=IP:<ip address: xx.xx.xx.xx>")
  1. Move the certificates to the resources/certificates/ directory for CFS to use.

On CFS host, enter:

cp /tmp/server.crt resources/certificates/
cp /tmp/server.key resources/certificates/
  1. Setup the override.yaml by modifying the file_server_root to https:
FILE_SERVER_URLROOT: "https://xx.xx.xx.xx:30220"
Enable certificate in the cfs-override-values.yaml
certificates:
  enabled: true
  serverCert: "resources/certificates/server.crt"
  serverKey: "resources/certificates/server.key"
  1. On the WRC side of the configuration, enable the use of certificates for WRC related workflows:

    1. The input needs to specify:
      • cfs_use_custom_ssl_ca_bundle: true
      • file_server_use_custom_ssl_ca_bundle: true
    2. ca.crt contents needs to be copied to secret: cfs_ssl_ca_chain
  2. Verify the certificates are working with curl command:

curl https://xx.xx.xx.xx:30220 -v  --cacert ca.crt 
*   Trying xx.xx.xx.xx:30220...
* Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 30220 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: server.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  start date: Jan  2 01:29:50 2025 GMT
*  expire date: Dec 31 01:29:50 2034 GMT
*  subjectAltName: host "2620:10a:a001:aa0c::70" matched cert's IP address!
*  issuer: CN=2620:10a:a001:aa0c::70
*  SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP OK
  Server: nginx
  Date: Thu Jan :42:06 GMT
  Content-Type: texthtml
  Transfer-Encoding: chunked
  Connection: keep-alive
  html>
<head><title>Index of /</title></head>
<body>
<h1>Index of /</h1><hr><pre><a href="../">../</a>
</pre><hr></body>
</html>