Air-gapped Artifactory install silently uses Derby and local filestore
Contoso must install Artifactory 7.77.5 on RHEL 8 in an air-gapped data center. The host has no internet access; packages are staged from a mirror. They will use an external PostgreSQL 13 database and an NFS mount for the filestore. An engineer installs the RPM, edits $JFROG_HOME/artifactory/var/etc/db.properties with the database URL and credentials, starts artifactory, and completes the onboarding wizard. Two weeks later the team discovers all repositories and build metadata are in an embedded Derby database on local disk, not PostgreSQL, and the filestore is also local. The service is running, but the database is growing and backups are not captured. They also need to expose the UI at https://artifactory.contoso.internal through an F5 reverse proxy, but the UI currently redirects to http://localhost:8082. They have a maintenance window and a 2 TB filestore.
1. Why did Artifactory ignore `db.properties` and use embedded Derby? What is the correct configuration path and sequence for a clean reinstall or supported migration?
Read the worked answer
Why the config was ignored
Artifactory 7.x reads system.yaml and binarystore.xml as the source of truth. db.properties is legacy and is generated or overwritten by the platform; editing it before first start did not configure the external database. The onboarding wizard then completed against the embedded Derby database and the default local filestore. Repointing a running instance at an empty PostgreSQL database would not migrate the two weeks of metadata.
Correct sequence
- Take a maintenance window and stop Artifactory.
- Back up the Derby database, the local filestore,
system.yaml,binarystore.xml, and the master key. - Decide whether to preserve data. For preservation, use the supported database migration or export/import procedure; do not hand-copy Derby files into PostgreSQL. For a clean install, remove the Derby data only after backup.
- In
system.yaml, set the PostgreSQL type, URL, driver, username, and password before the first start. Configure the NFS filestore inbinarystore.xmlwith the correct path and permissions. - Start the service, verify the database connection and filestore write, then restore or recreate repositories and build info.
Validate with the system configuration and health APIs, and confirm the artifactory user can write to NFS.
2. The F5 terminates TLS and forwards to router port 8082. What headers and settings must be configured, and how would you validate the result?
Read the worked answer
Reverse proxy requirements
The F5 should terminate TLS and forward to the Artifactory router on port 8082, not directly to the internal Artifactory port. Preserve the original Host header and add X-Forwarded-Proto: https, X-Forwarded-Host: artifactory.contoso.internal, and X-Forwarded-Port: 443. If the F5 rewrites the path, keep it consistent; do not strip the router prefix. Set the platform's public base URL to the external HTTPS URL so generated redirects and links do not point at localhost:8082.
Validation
From outside, request the UI and confirm the redirect Location uses https://artifactory.contoso.internal. Check /api/system/ping through the proxy, then log in and download an artifact. Inspect the F5 logs for 502 and 504 errors, and the Artifactory request log for the forwarded host. Test WebSocket or UI behavior if the version uses it. Do not open 8081 or 8082 directly to users; restrict them to the proxy and admins.
3. How would you structure the maintenance window, backup, go/no-go checks, and rollback for this migration?
Read the worked answer
Window and rollback
Back up the PostgreSQL database with a consistent dump, snapshot or copy the NFS filestore, and export the current system.yaml and binarystore.xml. Record the exact RPM version and license. Run the migration in a staging clone first with the same PostgreSQL major version and NFS client. During the window, stop writes, take the final backup, run the supported migration, and start the new configuration.
Go/no-go checks
- The service health endpoint passes and all nodes see the external database and NFS mount.
- A test artifact upload and download works through the proxy.
- Build-info and a sample repository resolve.
- Database size and filestore checksums match expectations.
Rollback
If validation fails, stop the service, restore the pre-window database and filestore together, restore the previous RPM and configuration, and start. Do not mix a restored database with a filestore from a different point in time. Keep the window open until replication and backups are confirmed.