Deployment profiles and SSH¶

A deployment profile is versioned non-secret infrastructure policy. Every execution pins the resolved profile snapshot, so later edits affect only future runs.

Choose a backend¶

INPUTpatched graphimmutable artifact

TRANSLATEDALiuGE TMlogical to physical

OPTION AREST DIMdeploy + poll HTTP

OPTION BSlurmSSH + SFTP + sbatch

Kind	Use when	Prove before enabling
`rest_remote`	A DALiuGE Data Island Manager already runs	worker-to-TM, TM-to-DIM, worker-to-DIM connectivity and TLS
`slurm_remote`	DALiuGE should start inside an HPC allocation	SSH trust, account/partition, paths, runtime environment, `sbatch`/`squeue`/`sacct`

Profiles never contain private keys, passphrases, provider passwords, or tokens.

Create a profile¶

Setup may install a profile during the wizard or with --profile-config. You can also install one later:

REST remoteSlurm remote

beampipe profile add -f config/deployment_profile.dlg-dim.json
beampipe profile validate dlg-dim
beampipe profile render dlg-dim

beampipe profile add -f config/deployment_profile.slurm-remote.json
beampipe profile validate slurm-remote
beampipe profile render slurm-remote

Place operator-owned copies in a private directory if you do not want to edit the examples in config/. File validation occurs during profile add. profile validate accepts an installed profile name.

Common fields¶

{
  "name": "slurm-hpc",
  "description": "Science pipeline qualification profile",
  "project_module": "science_pipeline",
  "is_default": true,
  "max_concurrent_executions": 1,
  "translation": {
    "algo": "metis",
    "num_par": 1,
    "num_islands": 1,
    "tm_url": "https://translator.example.org"
  },
  "deployment": {"kind": "slurm_remote"}
}

project_module=null makes a profile global. Project automation resolves deployment_profile_name; otherwise Beampipe uses the applicable default. Keep max_concurrent_executions low until the target has passed a load qualification.

REST remote¶

{
  "kind": "rest_remote",
  "dim_host_for_tm": "dlg-dim.internal",
  "dim_port_for_tm": 8001,
  "deploy_host": "dlg-dim.example.org",
  "deploy_port": 8001,
  "use_https": true,
  "verify_ssl": true
}

translation.tm_url is the Translator Manager address visible from a Beampipe worker.
dim_host_for_tm is the DIM address visible from Translator Manager.
deploy_host is the DIM address visible from Beampipe workers.
Keep TLS verification enabled. Use trusted CA configuration instead of disabling it.
Validate the graph application/runtime package versions, not only endpoint health.

These are three network viewpoints, not aliases for one host. A containerized deployment might use http://dlg-tm.desk from Core to TM, dlg-dim:8001 from TM to DIM, and dlg-dim.desk:80 from Core to DIM through Traefik. Direct Docker service names are also valid when all callers share the network. Never substitute 127.0.0.1 without checking which process makes the connection; container loopback points back to that container. The direct WALLABY local DALiuGE qualification uses one-host loopback deliberately and is not a Core rest_remote profile qualification.

beampipe doctor --profile local-daliuge
beampipe daliuge inspect --profile local-daliuge
beampipe daliuge sessions --profile local-daliuge

Slurm remote¶

Required profile fields are login_node, account, absolute home_dir, log_dir, dlg_root, and a typed runtime_contract. Resource settings belong under resources; manager placement belongs under manager_topology.

{
  "kind": "slurm_remote",
  "login_node": "login.example.org",
  "ssh_port": 22,
  "remote_user": "operator",
  "ssh_credential": "hpc",
  "account": "project_account",
  "home_dir": "/scratch/project_account",
  "log_dir": "/scratch/project_account/operator/dlg/log",
  "dlg_root": "/scratch/project_account/operator/dlg",
  "modules": "module load singularity",
  "venv": "source /software/project/venv/bin/activate",
  "runtime_contract": {
    "required_commands": ["science_pipeline"],
    "required_python_modules": ["science_pipeline"],
    "required_environment": [
      {"name": "SCIENCE_PIPELINE_IMAGE", "kind": "readable_file"}
    ],
    "output_subdirectory": "science_outputs",
    "shared_staging_subdirectory": "science_staging_data",
    "output_environment_variable": "SCIENCE_OUTPUT_ROOT",
    "shared_staging_environment_variable": "SCIENCE_STAGING_ROOT"
  },
  "exec_prefix": "srun -l",
  "facility": "hpc",
  "resources": {
    "partition": "work",
    "nodes": 1,
    "tasks": 1,
    "cpus_per_task": 1,
    "memory": "32G",
    "wall_time_minutes": 60
  },
  "manager_topology": {
    "islands": 1
  }
}

beampipe profile render PROFILE_NAME shows effective #SBATCH directives and DALiuGE settings before submission.

The runtime contract is the project boundary. Core itself preflights only Slurm, Python, DALiuGE, and the writable dlg_root. Every additional executable, Python module, host environment value, directory name, and directory environment binding must be declared by the profile. non_empty environment requirements are checked for a value; readable_file additionally verifies a readable regular file on the login node. Values come from the Beampipe process and are forwarded into the outer allocation, while profiles store names only. BEAMPIPE_SLURM_ACCOUNT and PYTHONPATH are Core-managed and cannot be used as contract variable names.

output_subdirectory and shared_staging_subdirectory are safe names beneath dlg_root, not arbitrary absolute paths. Their optional environment-variable fields expose the resolved locations to project code. This keeps Core neutral while making every runtime dependency reviewable and revision-pinned.

environment_setup remains available for operator-reviewed shell initialization that cannot be expressed by the typed contract. It runs before DALiuGE creates the job script and again in the shell that invokes sbatch. Do not use it as an implicit environment-forwarding mechanism.

Beampipe always derives BEAMPIPE_SLURM_ACCOUNT from deployment.account, so outer and nested allocations cannot drift. The bundled WALLABY profile explicitly declares wallaby_hires, Singularity, its Python module, BEAMPIPE_ASKAPSOFT_SIF, wallaby_outputs, and wallaby_staging_data; none is a generic Slurm default. Existing Slurm profile files without runtime_contract must be revised before installation. The bundled profile is deliberately not a default: edit and qualify its account, paths, credentials, and SIF before selecting it.

Preferred SSH key model¶

Profiles store only a non-secret slot name. The slot is a directory under the credential root, not a hostname. Every installation has one deterministic credential root:

$BEAMPIPE_HOME/credentials/ssh/
|-- known_hosts
`-- hpc/
    |-- private_key
    |-- private_key.pub
    |-- passphrase
    `-- known_hosts

The host runtime reads this tree directly. The release Compose bundle mounts the same absolute host path read-only at /run/beampipe/ssh in API, scheduler, and worker services. Keys are never copied into images or containers.

GET /api/v2/slurm/credentials (and Dash's profile picker) lists slot names and whether private_key, private_key.pub, passphrase, and known_hosts files are present. The responses never include key material. Init, import, and copy-id remain CLI.

Beampipe does not use ssh-agent. Workers unlock private_key plus an optional passphrase file. Choose one path: generate a Beampipe-owned key, or import a key you already have. Do not run ssh-keygen and init for the same slot.

Generate a Beampipe-owned key¶

init creates the Ed25519 key. You still must install private_key.pub on the login node before SSH will work. --copy-id (or the later copy-id command) is that install step when password SSH still works; otherwise use the site's key-registration process.

beampipe slurm credentials init \
  --slot hpc \
  --host login.example.org \
  --user alice \
  --port 22 \
  --acl
beampipe slurm credentials copy-id \
  --slot hpc \
  --user alice \
  --host login.example.org

Generation occurs inside Beampipe, so the passphrase is not exposed in an ssh-keygen process argument. Interactive init can prompt to run ssh-copy-id; --yes does not prompt.

Import an existing key¶

Use this when the key already exists (including a key created with ssh-keygen). The source key is not modified. Skip uploading the public key if the cluster already has it in ~/.ssh/authorized_keys. Prefer a facility-verified known_hosts file.

beampipe profile add \
  -f "$HOME/beampipe/config/deployment_profile.slurm-remote.json" \
  --ssh-slot hpc \
  --ssh-private-key "$HOME/.ssh/id_ed25519" \
  --ssh-known-hosts "$HOME/.ssh/known_hosts" \
  --ssh-acl

Or manage the slot separately:

beampipe slurm credentials import \
  --slot hpc \
  --private-key "$HOME/.ssh/id_ed25519" \
  --known-hosts "$HOME/.ssh/known_hosts" \
  --acl
beampipe slurm credentials sync --slot hpc
beampipe slurm credentials check --slot hpc --profile slurm-remote

For an encrypted key, pass --passphrase-file pointing to a protected file. Secret text is never accepted as a CLI argument.

Installing the public key¶

ssh-copy-id and a manual append both keep existing authorized_keys entries when you use >>. Some sites require a portal or helpdesk process instead.

# password SSH still works
beampipe slurm credentials copy-id --slot hpc --user alice --host login.example.org

# or append manually (use >> so existing keys are kept)
cat "$BEAMPIPE_HOME/credentials/ssh/hpc/private_key.pub" \
  | ssh alice@login.example.org "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Pawsey-style login nodes follow the same authorized_keys pattern. See Use of SSH Keys for Authentication. That guide also covers ssh-agent for interactive laptop SSH; Beampipe workers do not use the agent.

Permissions by runtime¶

Runtime	Expected ownership and access
Native host	Service-user or root-owned regular file, mode `0600` or `0400`
Linux Docker	Same private mode plus narrow read/traverse ACLs for container uid `10001`; `--acl` applies them
Docker Desktop	Private host copy under the installation; `sync` performs the authoritative in-container readability check
Kubernetes/systemd	Mount a secret/credential file and point the slot resolver at the mounted credential root

beampipe slurm credentials sync does not use docker cp. It verifies the recorded bind source and, when services are running, executes a read test as the actual scheduler and worker container user.

Production rejects symlinks, non-regular private keys, group/world permissions, unsupported ownership, empty passphrase files, home-key fallback, and inline key material.

Host-key trust¶

Obtain the public host key through a trusted facility channel. Use ordinary OpenSSH entries:

login.hpc.example ssh-ed25519 AAAAC3...
[login.hpc.example]:2222 ssh-ed25519 AAAAC3...

Hashed entries are not supported. Verification is host- and port-aware; unrelated keys do not satisfy the check.

When no file is supplied, the interactive credential command can run ssh-keyscan, print SHA-256 fingerprints, and ask for confirmation. Verify those fingerprints through the facility before accepting them. Non-interactive scanning requires the explicit --accept-host-key acknowledgement.

export BEAMPIPE_ENV=production
export BEAMPIPE_SLURM_SSH_STRICT_KNOWN_HOSTS=true
export BEAMPIPE_SLURM_SSH_ALLOW_HOME_FALLBACK=false
export BEAMPIPE_ALLOW_INLINE_SECRETS=false
export BEAMPIPE_ALLOW_INSECURE_SSH_HOST_KEYS=false

beampipe security check
beampipe doctor --profile PROFILE_NAME
beampipe slurm ping --profile PROFILE_NAME
beampipe scheduler status --profile PROFILE_NAME

Inline PEM, home-directory fallback, and disabled host-key checks are development or break-glass features. Do not make them normal deployment configuration.

Slurm scale checks¶

Before raising concurrency, qualify one run and then a paced batch. Watch login-node SSH/SFTP pressure, remote filesystem growth, TM availability, profile caps, and poll duration. Polling is batched by target through pooled SSH sessions, but submission still stages files per execution.

For the explicit WALLABY sample, a direct runner has qualified the no-download graph, application package, publisher, and receipt handoff against loopback DALiuGE NM, DIM, and TM services. It does not create or reconcile a Core rest_remote execution. Required output publication currently has a trusted Core retrieval path only on slurm_remote, through authenticated SSH/SFTP. The bundled Slurm profile has passed schema, rendering, and command tests only; a live qualification still requires the real account, SSH slot, paths, runtime modules, and BEAMPIPE_ASKAPSOFT_SIF. Pin DALiuGE and project application versions in that runtime and record them with every facility qualification.