Preparing the Local Mirror Host

Prepare the local mirror host, select the product repositories, and configure access to the upstream package repository before creating the air-gapped Data Fabric repository.

The air-gapped Data Fabric repository is available as a container.

The host machine (local mirror host) that hosts the air-gapped repository docker container must satisfy the following criteria::
  • Use a Linux host with Docker or Podman installed, running, and accessible to the operator.
  • Choose a hostname or IP address reachable from cluster nodes to advertise the host.
  • Install either ss or lsof so the air-gapped repository bootstrap script can check whether the selected host port is available.
  • Download the airgap-repository CLI from the HPE official repository. Pull the supported image from the maprtech docker registry, and pass it with --image IMAGE; use --local if the image is already available locally.

  • Ensure that the host running airgap repo container has sufficient disk space, considering the active publication, inactive publications, archive cache, sufficient head room for in progress repository updates or synchronization. See Disk Capacity and Preflight for details.

  • Allow access to the official HPE Data Fabric repository when you are creating or updating the air-gapped repository with credentials, when authentication is required.
  • Choose an unused host HTTP port and allow cluster nodes to reach the port. The default port is 8080.

Choose persistent data directory

Choose a persistent dedicated writable data directory to use as -data-dir parameter, this is where we store the dowloaded package archives persistently. The path must be absolute and canonical, without . or .. components or any symlink traversal. Do not use a top-level system directory such as /, /var, or /var/lib.

Choose a data directory based on the following considerations:1. 2. .3. 4.

Use the following considerations while choosing a data directory:
  • Choose a path that does not exist yet or an empty directory while creating the air-gapped repository.
  • Do not choose directories that contain nested mounts
  • For update, specify the same data directory that you have used during the air-gapped repository creation.
  • The airgap-repository bootstrap script creates a managed repository marker. Data Fabric validates the repository marker when re-using the data directory during the update operation.

Choose Core version, DEP version, and Operating System repositories

Select a supported Core and DEP combination using the compatibility information for the selected release. Each version or OS option accepts one or more space-separated values. Core and DEP versions use X.Y.Z form.
Table 1.
Component Required selection When required
Core --core-versions VER [VER...]--core-os OS [OS...] Supply both only when Core is selected.
DEP / ecosystem pack --mep-versions VER [VER...]--mep-os OS [OS...] Supply both only when DEP is selected.
Installer --installer-os OS [OS...] Supply only when Installer is selected. No version argument.

Select at least one component. Use the exact values in Supported Operating Systems. For Core ubuntu22 or ubuntu24, DEP and Installer still use the family selector ubuntu.

NOTE
The Core version , Core OS repo selection is independent of DEP or installer version or OS selection. For a given Core/DEP version all the selected supported OS packages are downloaded to the persistent data directory. Use the airgap-repository update command, to bring in newly selected OS packages to persistent data directory, after initial airgap repository is setup. See Updating the Air-gapped Repository for details on the airgap-repository update command.

Choose release-compatible versions and the published build values in Supported Operating Systems. An OS selection for Core does not automatically select DEP or Installer, and their selector names do not have to be identical.

Provide a compatible package downloader

By default, the airgap-repository CLI uses mapr-setup.sh to download the repository archives to the local airgap repository. This mapping is done automatically in the background. However, you can choose to specify a custom mapr-setup.sh by using the options --mapr-setup-file or -mapr-setup-url . For the custom mapr-setup.sh, you must use the same path or URL for repository updates.

Configure repository authentication

For an authenticated upstream repository, use a protected structured configuration file outside the persistent data directory.
  1. Create a new mode-0600 file and edit it. These preparation commands initialize a new file; do not use them to overwrite a configuration you need to retain.
    install -m 600 /dev/null /root/airgap-repository.conf
vi /root/airgap-repository.conf
  2. Add each of the following keys exactly once, replacing the example values:
    repository_url=https://package.example/releases
username=USERNAME
password=PASSWORD
  3. Pass --repo-config-file /root/airgap-repository.conf to create and update. Use raw username and password values. Do not append /installer/ubuntu/mapr-setup.sh.
    NOTE
    Do not pass a credential-bearing URL directly through --repo-url. Keep configuration files readable only by the operator and outside the persistent data directory. Restrict host access while synchronization runs because the retrieved mapr-setup.sh can expose parsed credentials in child-process arguments. Protecting the input file does not remove that downstream exposure risk.

    For an unauthenticated repository, use --repo-url URL with a credential-free repository root. Protected legacy URL inputs remain available through --repo-url-file FILE and --repo-url-stdin. Provide exactly one repository source.

    These credentials authenticate upstream downloads. They do not configure authentication for clients of the mirror's HTTP endpoint.

Configure a proxy or private CA

You can specify the network proxy config HTTP_PROXY/HTTPS_PROXY/NO_PROXY (strictly upper case) in a file and pass it in the option -network-config-file FILE. You can specify the same info inline using --http-proxy, --https-proxy, or --no-proxy options.

Use the --ca-cert FILE with a readable, nonempty CA certificate file when upstream TLS requires a private CA. Pass the proxy and CA options for the airgap-repository create and update operations.

Operating guidelines

  • Always reuse the same data directory (specified with the --data-dir parameter) for cumulative updates.
  • Do not manually edit the active repository symlink or files in the active publication.
  • Do not manually delete publication or staging directories while synchronization is running.
  • The synchronization helper and serving container share the same persistent host mount. Do not use the docker cp command to move repository content between them.
  • Keep repository credentials and proxy configuration outside the persistent repository directory.
  • Only one publication is active at a time. Plan for candidate and retained inactive publications; do not assume automatic cleanup or a supported rollback procedure.
  • Use remove to delete the serving container. Use purge-data --yes only for permanent deletion of persistent repository content and caches.
  • Serving-only lifecycle commands are offline operations. Keep the serving container running for update.