Egeria 5.3 on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Egeria 5.3 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Egeria is an open source project from the Linux Foundation AI & Data foundation that delivers open metadata and governance: open standards and runtime services for sharing metadata about data assets across the many tools, catalogues and platforms an organisation runs. Its OMAG Server Platform hosts one or more logical metadata servers, each exposing REST APIs for cataloguing assets, tracking lineage, classifying data and coordinating governance.

The image runs the official Egeria OMAG Server Platform 5.3 (org.odpi.egeria:platform-chassis-spring, Apache-2.0), verified against a sha256 checksum at build time, on OpenJDK 17 as a single Java process. A working in memory Metadata Access Store server named active-metadata-store is configured and activated automatically, so the running appliance serves live open metadata — its full Open Metadata type system and the Open Metadata Repository Services (OMRS) REST API — the moment it boots. Because Egeria's platform authentication is intentionally minimal, the appliance fronts the API with an nginx reverse proxy that enforces per VM HTTP Basic authentication, so nothing is exposed without a credential unique to your machine.

What is included:

• Egeria OMAG Server Platform 5.3 (platform-chassis-spring, Apache-2.0), sha256-pinned, plus the sha256-pinned connector library it loads (file configuration store, in memory repository, audit log)
• OpenJDK 17 JRE headless (the Java baseline the upstream project targets)
• egeria-platform.service systemd unit auto-starting the OMAG Server Platform on boot as the unprivileged egeria:egeria system user
• egeria-activate.service systemd unit that activates the configured active-metadata-store server on every boot, idempotently and fault-tolerantly
• egeria-firstboot.service systemd oneshot that generates a per-VM HTTP credential and a per-VM TLS certificate before the service is exposed
• The OMAG Server Platform REST API bound to loopback only (127.0.0.1:9443) — nginx fronts it on :443 with HTTP Basic authentication
• The interactive Swagger UI at /swagger-ui/index.html rendering the running platform's REST API
• Unauthenticated /healthz endpoint (nginx-native, HTTP 200) wired to the platform origin for load balancer / probe checks
• The server configuration documents and platform logs on a dedicated 20 GiB Azure data disk mounted at /var/lib/egeria, so server definitions survive independently of the OS disk
• Ubuntu 24.04 LTS base with latest security patches applied at build time and unattended security updates enabled
• Azure Linux Agent for seamless cloud integration and SSH key injection
• 24/7 cloudimg support with guaranteed 24 hour response SLA

Architecture

The OMAG Server Platform listens on 127.0.0.1:9443 only. It is never exposed directly to the network — nginx terminates :443 (with a per-VM self-signed certificate) and reverse proxies to the loopback platform, and the Azure Network Security Group opens only ports 22, 80 and 443. Port 80 redirects to 443. This keeps the metadata API and Swagger UI behind a single, auditable, authenticated nginx front door.

Step 1: Deploy the image

Launch the Egeria 5.3 on Ubuntu 24.04 LTS by cloudimg image from the Azure Marketplace on a Standard_B2s (or larger) VM. Open inbound ports 22 (SSH), 80 (HTTP) and 443 (HTTPS) in the Network Security Group. The 20 GiB data disk that carries the server configuration is provisioned automatically from the image.

Once the VM is running, connect over SSH as azureuser with the SSH key you selected at launch:

ssh azureuser@<public-ip>

Step 2: Confirm the services are running

The platform, the server activator and nginx start automatically on boot. Confirm all three are active:

systemctl is-active egeria-platform.service egeria-activate.service nginx.service

Each command should print active. For the full status view:

systemctl --no-pager status egeria-platform.service egeria-activate.service nginx.service

Step 3: Retrieve the per-VM credential

No default password is baked into the image. On first boot the appliance generates a unique HTTP Basic credential (user admin) and writes it, together with the service URLs, to a root-only file:

sudo cat /etc/cloudimg-credentials.txt

The file lists EGERIA_URL, EGERIA_SWAGGER_URL, the configured EGERIA_SERVER, the API user id, and the admin credential you use for the Swagger UI and REST API.

Step 4: Open the Swagger UI

In your browser, open the Swagger UI at https://<public-ip>/swagger-ui/index.html. The appliance uses a per-VM self-signed certificate, so accept the browser's certificate prompt, then sign in with user admin and the password from Step 3. The Swagger UI renders the running platform's full REST API — Egeria's Open Metadata and Governance (OMAG) Server Platform, version 5.3.

Step 5: Explore the metadata REST API

Scroll the Swagger UI to browse the platform, administration, repository and access-service operations. Each group can be expanded, and any operation can be tried live against the running server with the Try it out button.

Step 6: Verify the configured metadata server

From the VM, confirm the platform is serving and the active-metadata-store server is active. The commands read the per-VM credential straight from the credentials file, and use -k because the loopback listener presents the appliance's self-signed certificate:

curl -ks https://127.0.0.1/healthz

That prints the platform origin string, confirming Egeria is up. Now list the active servers through the authenticated front door:

PASS=$(sudo grep '^EGERIA_PASSWORD=' /etc/cloudimg-credentials.txt | cut -d= -f2-)
curl -ks -u "admin:${PASS}" \
  https://127.0.0.1/open-metadata/platform-services/users/garygeeke/server-platform/servers/active

The response lists active-metadata-store in its serverList, confirming the configured metadata server is running the Open Metadata Repository Services (OMRS).

The same response viewed through the browser's authenticated session:

Step 7: Query the open metadata type system

The running server loads Egeria's full Open Metadata type system into its in memory repository. Retrieve the type count to confirm live metadata is being served:

PASS=$(sudo grep '^EGERIA_PASSWORD=' /etc/cloudimg-credentials.txt | cut -d= -f2-)
curl -ks -u "admin:${PASS}" \
  https://127.0.0.1/servers/active-metadata-store/open-metadata/repository-services/users/garygeeke/types/all \
  | python3 -c 'import sys,json; print("open metadata typeDefs loaded:", len(json.load(sys.stdin).get("typeDefs", [])))'

You can explore and call every metadata, administration and repository operation from the Swagger UI.

Step 8: Where the data lives

The OMAG Server Platform's working directory, its server configuration documents and its platform logs live on the dedicated 20 GiB Azure data disk mounted at /var/lib/egeria:

findmnt /var/lib/egeria
ls /var/lib/egeria/data/servers/active-metadata-store/config/

The configuration document for active-metadata-store is what lets the platform re-activate the server automatically on every reboot. The in memory repository content itself is deliberately non-persistent — it is rebuilt from the loaded type system each time the server starts.

Managing the service

Restart the platform (the configured server is re-activated automatically):

sudo systemctl restart egeria-platform.service

Stop or start the platform:

sudo systemctl stop egeria-platform.service
sudo systemctl start egeria-platform.service

View the platform logs:

journalctl -u egeria-platform.service --no-pager | tail -50

Security notes

• No default credential. The captured image ships no HTTP password and no TLS private key. On first boot the appliance generates a per-VM admin credential and a per-VM self-signed TLS certificate, and only then exposes nginx on :443.
• Loopback only. The OMAG Server Platform binds 127.0.0.1:9443. The only network-reachable entry point is nginx, which enforces HTTP Basic authentication on every path except the unauthenticated /healthz probe.
• Least privilege. The platform runs as the unprivileged egeria system user with NoNewPrivileges, ProtectSystem and PrivateTmp hardening.
• Rotating the credential. Replace the admin credential at any time with sudo htpasswd -B /etc/nginx/.htpasswd admin followed by sudo systemctl reload nginx.
• Use a trusted certificate. For production, replace the per-VM self-signed certificate at /etc/nginx/ssl/egeria.crt and /etc/nginx/ssl/egeria.key with a CA-issued certificate and reload nginx.

Troubleshooting

• Swagger UI or API returns 401: you are missing the HTTP Basic credential. Use user admin and the password from /etc/cloudimg-credentials.txt.
• active-metadata-store not listed as active: check systemctl status egeria-activate.service and journalctl -u egeria-activate.service; the activator waits for the platform and then starts the server.
• Certificate warning in the browser: expected — the appliance uses a per-VM self-signed certificate. Replace it with a CA-issued certificate for production (see Security notes).
• Platform slow to answer right after boot: the Spring Boot platform takes a few seconds to initialise; curl -ks https://127.0.0.1/healthz returns the origin string once it is ready.

Support

Every cloudimg image comes with 24/7 support and a guaranteed 24 hour response SLA. For assistance with this image, contact cloudimg support through the Azure Marketplace listing.