Remote Data Broker

Remote Data Broker (RDB) is a low-level service within the NDIP data management solution. It serves files to other NDIP components over HTTP. Rucio's https protocols point at RDB endpoints (https://<host>/v0.1/...). A gateway receives the HTTP request and passes it through RabbitMQ to the worker named by ?remotequeue=. The worker reads the file from storage it can mount.

Code

The service is written in Go. Its source code, with build, configuration and usage instructions, is here.

Deployment

On the clusters

Object	What
Helm release rdb-galaxy (chart remote-data-broker, image 0.5.3)	Gateway + worker in one pod. Mounts the galaxy-data PVC read-only at /galaxy/data and consumes queue galaxy (prod) or galaxy-test (test) on the in-cluster RabbitMQ. Serves the GALAXY/GALAXY_TEST RSE to Pulsar hosts that can't mount the PVC
Ingress rdb-sns-facility + ExternalName Service rdb-sns-gpu	https://<host>/v0.1 → the RDB gateway on sns-ndip-gpu.sns.gov (port 9001 prod, 9002 test). That gateway dispatches on ?remotequeue=, so GALAXY* requests come back to rdb-galaxy through RabbitMQ

Deployed by rdb-test / rdb-k8s-prod (k8s/rdb/deploy.sh, values values-galaxy.yml rendered from k8s/env/<env>.env). Not part of the full-stack job.

On compute hosts (Ansible)

RDB gateways/workers run as the rdb systemd service next to Pulsar, deployed by the Pulsar jobs (role ornl.tuning.pulsar, task rdb.yml; settings in ansible/group_vars/pulsar_all_servers/pulsarservers.yml):

• sns-ndip-gpu.sns.gov: the gateway behind /v0.1, plus facility workers;
• ndip-node01.sns.gov: the sns-ndip RDB (port 9001, queue sns-ndip; Rucio RSE SNS_NDIP). The prod sns-ndip RDB on node01 has been running since the migration and consumes queue sns-ndip on speedy (checked 2026-10-06).

Slate and Spin

Installed manually with Helm (two-factor authentication): see the Slate README and the Spin deployment script.

The /v0.1 endpoint is public and unauthenticated

Every RDB runs with auth off (rdb_auth_enabled: false). The worker serves a request by running cat $filename on the requested path. rdb-galaxy mounts the whole galaxy-data PVC, so anything under /galaxy/data can be read by anyone who can reach https://<host>/v0.1/download. File names are hashes, which is obscurity, not access control. Turning on rdb.auth alone doesn't fix this, because an empty user list rejects everyone. The planned fix is to restrict the Ingress to the Pulsar hosts (nginx.ingress.kubernetes.io/whitelist-source-range) and make the RDB reject paths outside its prefix. Source-IP restriction only works once the F5 preserves client IPs, which the VM proxy does not.

Checks

kubectl -n ndip get pods -l app.kubernetes.io/instance=rdb-galaxy
kubectl -n ndip logs deploy/rdb-galaxy
kubectl -n ndip exec galaxy-rabbitmq-0 -- rabbitmqctl list_queues name consumers | grep -E '^(galaxy|sns-ndip)'

On a compute host: systemctl status rdb, logs in /var/log/rdb.log. The RDB depends on its data mounts (/SNS, /HFIR, /ceph). See Known issues.

Legacy

On the VM stack, the RDB ran as a system service on ndip(-test).ornl.gov (Ansible task ornl.tuning/tasks/rdb.yml, group_vars/galaxyservers/rdb.yml), and the VM's nginx proxied /v0.1 to the sns-gpu gateway.