|Index|CloudCasa Self-Hosted with SUSE Virtualization
SUSE Virtualization

CloudCasa Self-Hosted with SUSE Virtualization

Data protection for isolated virtual machine environments

Technical Reference Documentation
Getting Started
Authors
Gopala Krishnan A, Partner Solution Architect (SUSE)
Suresh Sekar, Partner Solution Architect (SUSE)
SUSE Virtualization
CloudCasa Self-Hosted
Date: 2026-09-15
Summary

This guide provides step-by-step instructions for deploying CloudCasa™ Self-Hosted to protect your air-gapped SUSE® Virtualization environment with cloud native backup, disaster recovery, migration, and replication.

Disclaimer

Documents published as part of the series SUSE Technical Reference Documentation have been contributed voluntarily by SUSE employees and third parties. They are meant to serve as examples of how particular actions can be performed. They have been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. SUSE cannot verify that actions described in these documents do what is claimed or whether actions described have unintended consequences. SUSE LLC, its affiliates, the authors, and the translators may not be held liable for possible errors or the consequences thereof.

1 Key takeaways

Deploying SUSE Virtualization and CloudCasa Self-Hosted together provides:

  • Full control for regulated or air-gapped environments via self-hosting.

  • Business continuity for container and Kubernetes-native virtual machine workloads.

  • Centralized backup and recovery for virtual machines and persistent volumes.

  • Validated end-to-end backup and recovery workflows.

2 Introduction

Modern enterprises are turning to open-source, Kubernetes-based virtualization platforms such as SUSE Virtualization to break down infrastructure silos, lower licensing expenses, and unify the management of virtual machines (VMs) alongside cloud native containers. Maintaining a robust data protection strategy is crucial, even within isolated or air-gapped environments. CloudCasa Self-Hosted offers a cloud native backup and recovery solution designed to protect critical workloads, ensure operational continuity, and streamline disaster recovery.

Key objectives covered in this guide include:

  • Setting up a proof-of-concept environment by deploying CloudCasa Self-Hosted alongside a SUSE Virtualization cluster.

  • Verifying the backup and restoration process for virtual machines.

2.1 Scope

This guide covers the deployment of CloudCasa Self-Hosted onto a SUSE Rancher Kubernetes Engine (RKE2) cluster alongside an existing SUSE Virtualization cluster environment. Deployment includes installation and configuration of SUSE Linux Enterprise Server on a host system, deployment of RKE2 on this host, and installation of CloudCasa. After installation, the guide provides a simple validation by backing up and restoring a virtual machine.

2.2 Audience

This guide is intended for IT administrators, Kubernetes administrators, virtualization administrators, backup administrators, and solution architects responsible for deploying and managing CloudCasa Self-Hosted to protect SUSE Virtualization workloads.

2.3 Acknowledgments

The authors wish to acknowledge the contributions of the following individuals to the creation of this document:

  • Jonathan Garner, Senior Platform Engineer, Catalogic Software

  • Terry Smith, Partner Ecosystem Solution Innovations Director, SUSE

3 Architecture

CloudCasa Self-Hosted is cloud native and is deployed onto a Kubernetes cluster. In this architecture, the CloudCasa backup server is deployed onto a single-node SUSE Rancher Kubernetes Engine (RKE2) cluster, running on a SUSE Linux Enterprise Server virtual machine with network access to a SUSE Virtualization cluster.

arch svirt cloudcasa selfhosted
Figure 1: Architecture Overview

The technical components of the solution include:

CloudCasa Self-Hosted

CloudCasa (v1.6.7 or later) is a data protection and mobility solution for Kubernetes and cloud native applications. It was originally developed as a SaaS-only offering, but it is also available as this self-hosted option for installation on-premises or in customer cloud environments. CloudCasa Self-Hosted consists of a server, a database, agents installed on each client cluster, and external S3-compatible or Azure object storage used to store the backup data.

SUSE Virtualization

SUSE Virtualization (v1.8 or later) is the open source, cloud native, hyperconverged infrastructure (HCI) solution for organizations that need to run virtual machines and containers together in the data center, public clouds, and at the edge.

SUSE Rancher Kubernetes Engine (RKE2)

RKE2 (v1.34 or later) is SUSE’s enterprise-ready next-generation Kubernetes distribution. It is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector. To meet these goals, RKE2 provides defaults and configuration options that allow clusters to pass CIS Kubernetes Benchmarks with minimal operator intervention, enables FIPS 140-3 compliance, is regularly scanned for CVEs using trivy in SUSE’s build pipeline.

SUSE Linux Enterprise Server

SUSE Linux Enterprise Server (15 SP7 or later) is a modern, modular Linux operating system that provides a secure and stable platform for mission-critical workloads.

4 Preparing your environment

Before you begin the deployment, ensure that the required infrastructure, software access, and credentials are available. This guide assumes that a SUSE Virtualization environment is available as the target platform for backup and restore validation.

4.1 Sizing and configuration guidance

Deploy a virtual machine with the following minimum specifications:

  • vCPU: 4 minimum

  • RAM: 8GB minimum, 16GB recommended

  • OS disk: 100 GB

  • Network: static IP (recommended) with access to the SUSE Virtualization cluster management network.

4.2 Ensuring network access

  1. Make sure your firewall is configured to allow communication between the CloudCasa backup server and the SUSE Virtualization cluster nodes on port 443/tcp.

  2. Defining a local A DNS record to for the VM that will host the CloudCasa backup server, such as 'local.cloudcasa.io'.

Note
Note

The DNS record for local.cloudcasa.io must resolve to the SLES VM IP address across all client machines accessing the CloudCasa UI and any target Kubernetes cluster nodes. The local Envoy ingress server handles internal routing and TLS termination for CloudCasa traffic.

4.3 Setting up the SUSE Virtualization environment

Deploy and configure a SUSE Virtualization cluster (if you do not already have one). For detailed installation and configuration steps, refer to the SUSE Virtualization Documentation.

After deployment, verify that the SUSE Virtualization cluster is operational and that you can access its management interface.

4.4 Preparing CloudCasa access and credentials

Before installing CloudCasa Self-Hosted, ensure that you have the required credentials and license information. Do this by completing the following steps:

  1. Obtain access to the CloudCasa Support Portal using your email address and one-time login code.

  2. Download the CloudCasa license file from the Support Portal.

  3. Obtain the following credentials from the CloudCasa team:

    • Helm repository credentials.

    • Azure Container Registry (ACR) credentials required to pull CloudCasa container images.

Important
Important

Treat the Helm repository and container registry credentials as sensitive information. Follow your organization’s security practices and rotate credentials after completing the proof-of-concept evaluation.

4.5 Air-gapped environment considerations

For deployments in strict air-gapped or restricted network environments where direct access to external repositories (such as Helm and Azure Container Registry) is not permitted, perform the following preparation steps on an internet-connected host prior to installation:

  1. Download Helm charts and images: Pre-pull the CloudCasa Helm chart and required container images from cloudcasa.azurecr.io on an internet-connected system using tools such as helm pull and docker pull or crane.

  2. Transfer assets to the air-gapped environment: Export container images to archive files using docker save or bundle them with crane export, then transfer the archives and chart packages into the isolated network environment using approved media or secure transfer jump hosts.

  3. Populate local registry and mirror: Import the container images into an internal container registry (for example, Harbor or an internal OCI registry) and host the Helm chart in an internal repository. Update your cloudcasa-values.yaml configuration file to reference the internal registry mirrors and credentials.

5 Installing SUSE Linux Enterprise Server and RKE2

This section describes how to prepare the operating system and deploy a single-node RKE2 cluster that will host the CloudCasa Self-Hosted services.

For additional product information, refer to the following documentation:

  • SUSE Linux Enterprise Server Documentation

  • SUSE Rancher Kubernetes Engine (RKE2) Documentation

    1. Register the SLES system using SUSEConnect and enable the required modules.

      SUSEConnect -r <YOUR_SUSE_REGISTRATION_CODE> -e <YOUR_EMAIL_ADDRESS>
      SUSEConnect -p sle-module-basesystem/<15.7>/x86_64
      SUSEConnect -p sle-module-server-applications/15.7/x86_64
      Note
      Note

      This example illustrates registering the required modules for SUSE Linux Enterprise Server 15 SP7. If you are using a later version, be sure to adjust the module names accordingly.

    2. Install the required base packages.

      sudo zypper install -y curl wget tar nfs-client jq
    3. Install and enable the iSCSI daemon for CSI/PV support.

      sudo zypper install -y open-iscsi
      sudo systemctl enable --now iscsid
    4. Install and start the RKE2 Kubernetes cluster.

      curl -sfL https://get.rke2.io | INSTALL_RKE2_VERSION="<RKE2_VERSION>" sh -
      sudo systemctl enable rke2-server.service
      sudo systemctl start rke2-server.service
      Note
      Note

      Replace <RKE2_VERSION> with the appropriate value, such as v1.34.2+rke2r1.

    5. Configure kubectl access for your environment, matching the installed Kubernetes version, and confirm the node is ready.

      mkdir -p ~/.kube
      sudo ln -s /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/kubectl
      export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
      echo 'export KUBECONFIG=/etc/rancher/rke2/rke2.yaml' >> ~/.bashrc
      echo 'export PATH=$PATH:/var/lib/rancher/rke2/bin' >> ~/.bashrc
    6. Deploy the local-path-provisioner as the default storage class.

      kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/<LPP-VERSION>/deploy/local-path-storage.yaml
      kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
      Note
      Note

      Be sure to specify the appropriate stable release version of the local-path-provisioner in place of <LPP_VERSION>

      Important
      Important

      The local-path provisioner is used here for simplicity. For production environments, it is best practice not to use local-path storage, as data may be lost if the pod is rescheduled.

6 Installing CloudCasa

This section describes how to deploy CloudCasa Self-Hosted on the RKE2 cluster using Helm. The deployment includes configuring the required Kubernetes resources, creating the image pull secret, deploying the CloudCasa server, and configuring ingress to access the CloudCasa Web interface.

For detailed product information and the latest deployment guidance, refer CloudCasa Self-Hosted Documentation

  1. Install Helm 3 to manage Kubernetes packages.

    curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | DESIRED_VERSION="<HELM_VERSION>" bash
    Note
    Note

    Replace <HELM_VERSION> with the appropriate version, such as v3.12.3 or later.

  2. Install cert-manager and create a self-signed issuer for the proof-of-concept.

    helm repo add jetstack https://charts.jetstack.io
    helm repo update
    
    helm install cert-manager jetstack/cert-manager \
      --namespace cert-manager \
      --create-namespace \
      --version <CERT_MANAGER_VERSION> \
      --set installCRDs=true
    
    kubectl create ns cloudcasa-server
    
    kubectl -n cloudcasa-server apply -f - <<EOF
    apiVersion: cert-manager.io/v1
    kind: Issuer
    metadata:
       name: selfsigned-issuer
    spec:
       selfSigned: {}
    EOF
    Note
    Note

    Be sure to replace <CERT_MANAGER_VERSION> with the desired version (v1.12.4 or later).

  3. Create the image pull secret using the ACR credentials provided by the CloudCasa team. These allow Kubernetes to pull container images from cloudcasa.azurecr.io.

    kubectl create secret docker-registry myregistrykey \
       --docker-server=https://cloudcasa.azurecr.io \
       --docker-username='<YOUR_ACR_USERNAME>' \
       --docker-password='<YOUR_ACR_PASSWORD>' \
       --namespace=cloudcasa-server
  4. Add the CloudCasa Helm repository using the Helm credentials provided by the CloudCasa team. These are separate from the ACR credentials above and are used only to download the Helm chart.

    helm repo add cloudcasa https://helm.cloudcasa.io \
       --username '<YOUR_CLOUDCASA_USERNAME>' --password '<YOUR_HELM_PASSWORD>'
    helm repo update
  5. Create cloudcasa-values.yaml with your configuration. The credentials under auth.local.users are new credentials you define yourself for logging in to the CloudCasa UI and are not related to the ACR or Helm credentials above.

    storageClassName: local-path
    licenseKey: <YOUR_DOWNLOADED_LICENSE_KEY>
    auth:
      local:
        enabled: true
        users:
          - email: "<YOUR_EMAIL_ADDRESS>"
            username: "<YOUR_USERNAME>"
            password: "<YOUR_PASSWORD>"
      ldap:
        enabled: false
      oidc:
        enabled: false
      cognito:
        enabled: false
      microsoft:
        enabled: false
      google:
        enabled: false
      allowedUsers: "<YOUR_EMAIL_ADDRESS>"
      siteadminUsers: "<YOUR_EMAIL_ADDRESS>"
    
    serviceType: NodePort
    
    amdsEnvoyUrl: local.cloudcasa.io
    amdsEnvoyPort: 443
  6. Install the CloudCasa server using Helm.

    helm install cloudcasa-server cloudcasa/cloudcasa-server --create-namespace \
       --namespace cloudcasa-server --wait --timeout 15m0s \
       --values cloudcasa-values.yaml
  7. Set the external URL, upgrade the deployment, and restart the Envoy TLS services.

    helm upgrade cloudcasa-server cloudcasa/cloudcasa-server --wait \
      --namespace cloudcasa-server --values cloudcasa-values.yaml
    kubectl -n cloudcasa-server delete secret amds-envoy.tls
    kubectl -n cloudcasa-server rollout restart deployments/amds-envoy
  8. Create and apply the Ingress manifest to expose the Envoy gRPC/HTTP API service externally on port 443.

    kubectl apply -f - <<EOF
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: amds-envoy-grpcapi
      namespace: cloudcasa-server
      annotations:
        kubernetes.io/ingress.class: nginx
        nginx.ingress.kubernetes.io/backend-protocol: "GRPCS"
        nginx.ingress.kubernetes.io/ssl-redirect: "true"
        nginx.ingress.kubernetes.io/proxy-body-size: "0"
      labels:
        amds-app: envoy
        amds.component: envoy
    spec:
      ingressClassName: nginx
      rules:
      - host: local.cloudcasa.io
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: amds-envoy-grpcapi
                port:
                  number: 443
    EOF
    Note
    Note

    It is best practice for production environments to configure a catalog backup to ensure metadata protection.

7 Configuring SUSE Virtualization

After deploying CloudCasa Self-Hosted, configure the SUSE Virtualization environment as the protected environment. CloudCasa Self-Hosted runs independently on the RKE2 cluster and connects to SUSE Virtualization to discover and protect workloads.

  1. Ensure local.cloudcasa.io is resolvable by adding an A record in your internal DNS server pointing to the IP address of your CloudCasa host.

  2. Log in to the CloudCasa UI at https://local.cloudcasa.io.

  3. Open the Add cluster Wizard.

  4. From the Dashboard, navigate to Clusters from the top navigation bar and select Add cluster.

    Dashboard Shortcuts and Add Cluster
    Figure 2: Dashboard Shortcuts and Add Cluster
    Note
    Note

    A browser certificate warning is expected if using a self-signed certificate. For production, replace the self-signed certificate with one issued by your internal CA.

  5. In the Add cluster dialog, enter the following information:

    • Name: Enter the name of your SUSE Virtualization cluster (for example, SUSE Virt).

    • Description (Optional): Provide a description for the cluster.

    • Tags (Optional): Add tags in the format key:value if required.

    • Enable CloudCasa DR (Optional): Toggle if disaster recovery is required.

  6. Expand Advanced options only if additional configuration is needed.

  7. Click Register to register the cluster with CloudCasa.

7.1 Installing the CloudCasa agent

After clicking Register, the Install Agent dialog appears.

  1. Ensure the Manual (kubectl) tab is selected.

    CloudCasa Agent Installation Command
    Figure 3: CloudCasa Agent Installation Command
  2. Click the Copy icon to copy the generated kubectl apply command.

  3. Log in to the SUSE Virtualization CLI (or a management host) that has:

    • kubectl installed.

    • Access to the SUSE Virtualization Kubernetes cluster.

    • The kubeconfig for the target cluster.

  4. Paste and execute the copied command in the terminal.

    Example:

    kubectl apply -f https://<cloudcasa-server>/api/kubeclusteragents/<agent-id>.yaml
    Note
    Note

    For CloudCasa Self-Hosted deployments using a self-signed certificate, enable the CloudCasa service is installed with self-signed certificate option before copying the command, if applicable.

7.2 Verify CloudCasa agent installation

  1. Wait a few minutes for the agent to start.

  2. Verify that the CloudCasa agent pods are running.

    kubectl get pods -n cloudcasa-io
  3. You should see the CloudCasa agent pods in the Running state.

7.3 Confirm the cluster is active

  1. Return to the CloudCasa UI.

  2. Click Close on the Install Agent dialog.

  3. Click Done in the Add Cluster pane.

  4. Navigate to Clusters > Overview.

  5. Wait for the cluster status to change from REGISTERED to ACTIVE.

    SUSE Virtualization Cluster Active in CloudCasa
    Figure 4: SUSE Virtualization Cluster Active in CloudCasa
  6. In the CloudCasa UI, navigate to Configuration > Storage.

  7. Add your target backup storage location, such as object storage (for example, AWS S3 or Azure Blob) or file storage (for example, NFS or CIFS).

  8. Ensure that the storage status is validated and active before proceeding to define and run backup jobs.

Note
Note

Only after the cluster becomes ACTIVE can you perform backup, restore, replication, or migration operations.

8 Validating the solution

To demonstrate that CloudCasa correctly protects and recovers a VM in your SUSE Virtualization cluster:

  1. Define and run a VM backup.

  2. Simulate data loss by deleting the VM.

  3. Restore the VM from backup.

  4. Verify VM data has survived.

8.1 Defining and running a backup

  1. Log in to the CloudCasa UI. From the top menu, navigate to Clusters.

  2. Select the Backups tab, then click Define Backup+.

  3. In the Define Cluster Backup wizard, select the target cluster and click Next.

    Select Cluster in Backup Wizard
    Figure 5: Select Cluster in Backup Wizard
  4. On the VMs/PVCs tab, enable Copy to backup storage to ensure persistent volumes are copied, then click Select resources.

  5. In the Browse cluster resources window, select the namespace and virtual machine to protect. Click Confirm, then Next.

    Browse Cluster Resources to Protect
    Figure 6: Browse Cluster Resources to Protect
  6. On the Summary screen, provide a name for the backup job, set the retention period (for example, 7 days), enable Run now, and click Create.

    Define Cluster Backup Summary
    Figure 7: Define Cluster Backup Summary
  7. Monitor the job from the Backups list. Open the Activity details to track progress. The job type displays as K8S COPY, and the PV Details tab shows persistent volumes as they are copied, mounted, and snapshotted.

    Backup Job Activity Details
    Figure 8: Backup Job Activity Details
  8. Wait until the job status changes to COMPLETED before proceeding.

    Important
    Important

    Do not proceed to the next step until the backup status shows COMPLETED. Restoring from an in-progress backup produces inconsistent results.

8.2 Simulating data loss

To simulate a genuine loss scenario, delete the VM along with its underlying data volumes.

  1. Switch to the SUSE Virtualization (Harvester) UI.

  2. Locate the virtual machine backed up in the previous procedure.

  3. Select the virtual machine and delete it, acknowledging the warning that associated snapshots and volumes are also removed.

    Confirm VM Deletion in Harvester
    Figure 9: Confirm VM Deletion in Harvester

8.3 Restoring the virtual machine

  1. Return to the CloudCasa UI and navigate to Clusters > Restores.

  2. Click Define Restore+.

  3. Select the source cluster and click Next.

  4. On the Recovery Point screen, select the backup job created in the previous procedure from the list of available snapshots and copies.

  5. Click Select resources. In the Recovery Point Browser, expand Virtual Machines and select the virtual machine to restore. Click Confirm.

    Select VM in Recovery Point Browser
    Figure 10: Select VM in Recovery Point Browser
  6. For Destination, select Use existing cluster and choose the original source cluster. Review the Restore Transforms options and click Next.

    Select Restore Destination Cluster
    Figure 11: Select Restore Destination Cluster
  7. On the Summary page, provide a name for the restore job and click Save & Restore to start the process.

  8. Monitor the restore job until it completes successfully.

    Restore Job Activity Details
    Figure 12: Restore Job Activity Details

8.4 Validating the restoration

  1. Return to the SUSE Virtualization UI and navigate to Virtual Machines.

  2. Confirm that the restored virtual machine appears in its original namespace. It starts in an Off state.

    Restored VM in Harvester UI
    Figure 13: Restored VM in Harvester UI
  3. Power on the virtual machine and open the console.

  4. Log in and verify that data created before the backup is still present (for example, read back a test file written before the backup procedure).

    VM Console Showing Restored Data Verification
    Figure 14: VM Console Showing Restored Data Verification

This successfully demonstrates that CloudCasa correctly restored both the virtual machine definition and its persistent data.

Important
Important

This does not validate Longhorn DR replication or the CloudCasa DR plan workflow.

9 Transitioning to production

The deployment described in this guide is intended as a proof-of-concept (POC) environment. For production environments, it is recommended to deploy a multi-node cluster with adequate memory resources and proper persistent volume (PV) storage rather than local-path storage. Additionally, authentication should be integrated with your organization’s authentication scheme, such as LDAP or OIDC. For further details, refer to the CloudCasa Self-Hosted Admin Guide.

10 Summary

This guide provides a reference design and guidance for a proof-of-concept deployment of CloudCasa Self-Hosted to provide data protection for virtual machines in an isolated SUSE Virtualization environment. Contact SUSE or Catalogic Software to explore production options to meet your unique business and technical requirements.

11 Frequently asked questions

  1. What is CloudCasa Self-Hosted?

    CloudCasa Self-Hosted provides you with the ability to deploy CloudCasa data protection in your own Kubernetes environment instead of using the CloudCasa SaaS platform. This approach addresses the data protection needs for isolated and air-gapped environments, where external network access is not possible.

  2. Can I use an identity provider like LDAP or OIDC?

    Yes, CloudCasa supports LDAP and OIDC integration.

  3. Is Docker required?

    No, CloudCasa Self-Hosted is runtime-agnostic and SUSE Rancher Kubernetes Engine (RKE2) uses the industry-standard container runtime, containerd.

  4. Do I need a valid CloudCasa license to deploy this proof-of-concept?

    Yes. A valid CloudCasa Self-Hosted license is required to deploy and evaluate the proof-of-concept described in this guide. Before you begin, obtain a license file and the required deployment credentials (such as the Helm repository and container registry credentials) from the CloudCasa Support Team. If you do not have access, contact Catalogic Software Support to request the necessary evaluation resources.

13 GNU Free Documentation License

Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

  15. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties—​for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

Copyright (c) YEAR YOUR NAME.
   Permission is granted to copy, distribute and/or modify this document
   under the terms of the GNU Free Documentation License, Version 1.2
   or any later version published by the Free Software Foundation;
   with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
   A copy of the license is included in the section entitled “GNU
   Free Documentation License”.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “ with…​Texts.” line with this:

with the Invariant Sections being LIST THEIR TITLES, with the
   Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.