Why some drivers are customer-installed
The standard agent image includes every driver whose licence allows DataNivra to redistribute it. Three vendor drivers have terms that do not:
| Connector | Driver | Vendor licence you accept |
|---|---|---|
| IBM Db2 (linux/amd64 only) | ibm_db 3.3.0, with IBM's CLI driver inside the wheel | IBM License Information L-WNKS-F8PR3U for the CLI driver (ibm_db itself is Apache-2.0); no Db2 Connect licence is included |
| Teradata | teradatasql 20.0.0.69 | Teradata License Agreement |
| SAP HANA | hdbcli 2.30.27 | SAP Developer License Agreement, or your own SAP agreement |
For these connectors you install the driver yourself, by building an extension image: a released DataNivra agent image plus the pinned driver. DataNivra provides and tests the recipe; the driver comes from the vendor, under the vendor's licence, to you. Without the driver the agent refuses the source with CONNECTOR_NOT_AVAILABLE and names the package; it never pretends to connect.
Each connector card on Integrations says "customer-installed driver" for these connectors.
What the extension image contains
The recipe lives in the DataNivra repository under agent/runtime/extensions/<connector>/ and has two files:
DockerfilebuildsFROM ghcr.io/manuelbomi/datanivra-agent@sha256:<digest>, the digest of a published agent release, so you know exactly which agent you extend.requirements.txtlists the driver and its dependencies at exact versions, with the SHA-256 of every file. The install step uses--require-hashes --no-deps --only-binary :all:: a file whose hash does not match is refused, nothing outside the list is installed and no package build script runs.
The image still runs as the non-root agent user (uid 10001), still has no inbound port and still sends only the metadata the privacy boundary allows. The driver runs inside your network like every other connector.
Build and run it
- Read the vendor licence in the table above. Building the image means you accept it.
- Copy
agent/runtime/extensions/ibm-db2/,teradata/orsap-hana/to a machine with Docker. - Change the
FROM ghcr.io/manuelbomi/datanivra-agent@sha256:...digest to the digest of the agent release you run. Each release's notes on Downloads show its digest and the cosign command that verifies it. - Build and push it to your own registry, for example
docker build -t registry.example.internal/datanivra-agent-teradata:0.4.1 .. Teradata and SAP HANA work on linux/amd64 and linux/arm64. IBM Db2 works on linux/amd64 only (--platform linux/amd64): IBM publishes no Linux arm64 driver, and the Db2 template stops an arm64 build. - Run the agent from that image instead of the standard one, with the same settings, volume and enrollment. With Helm, set
image.repositoryandimage.digestto your image. - Register the source as usual. The agent's preflight check (
datanivra-agent doctor --source-ref <reference> --connector TERADATA) confirms the connector is available in the new image.
Rebuild the extension image whenever you upgrade the agent, and when DataNivra updates a pinned driver version.
Status of these connectors
A connector with a customer-installed driver can reach Available only when this extension path is documented and tested, the agent fails closed without the driver, and a real conformance run, with the driver installed from exactly these pinned requirements, passes every check and the full workflow. IBM Db2 has a full real-engine run, but not yet one through this extension path, so it stays in preview until that run is recorded. Teradata and SAP HANA have no real-system run yet, so they are listed as coming next. See Integrations for the current status of each.