[andreasohlund]

Problem

RavenDB 6.2 reads License and License.Path only once, when a node with no cluster yet bootstraps one (ServerStore.EnsureNotPassiveAsync calls LicenseManager.TryActivateLicenseAsync). After that, it ignores the configured license.

So if the data volume mounted into servicecontrol-ravendb was first used by a RavenDB server without the ServiceControl license, for example the official ravendb/ravendb image or a volume reused from another setup, the database container stays on AGPL - Open Source. It doesn't apply the bundled license and logs nothing about licensing. Since 6.9 (#5235), the Error and Audit instances then stop at startup with Cannot validate the current RavenDB license. Please, contact support. This came up in a support case.

Change

Sets RAVEN_License_ThrowOnInvalidOrMissingLicense=true in the servicecontrol-ravendb image. With this RavenDB setting, the server checks at every startup whether a license is stored. If none is, it activates the license from License or License.Path. If that fails too, the server refuses to start and logs which configuration keys it tried.

Observable effect:

• A reused unlicensed volume is licensed when the container starts. No manual step is needed.
• A missing or invalid bundled license now stops the database container with a RavenDB error. Before, the container started on AGPL and the Error or Audit instance failed 30 seconds into its startup.
• Fresh volumes and volumes that already have a license behave as before.

Constraints:

• An expired stored license already stops RavenDB at startup, whatever this setting says. The setting only changes what happens when no license is stored.
• RavenDB documents the setting as "EXPERT ONLY". It's a supported configuration entry that Raven.Embedded and Raven.TestDriver also expose.
• The setting only affects the servicecontrol-ravendb image, which the bundled license is meant for. External, separately licensed RavenDB servers are not affected.

Alternatives considered

• Have the Error and Audit instances activate the bundled license when the server reports none. The instance can't tell our container apart from a customer's separately licensed RavenDB server, so it could put our license on a server it doesn't cover.
• Add a post-start activation step to sc-container-startup.sh. The base image's run-raven.sh supports this, but it does the same job as a built-in setting with more shell code to maintain, and it would need extra handling for servers secured with certificates.

Not in this PR: a clearer LicenseStatusCheck error message, and the same setting for the embedded database. Each is a separate change.

Verification

Built the image from this branch (BASETAG=6.2.18-ubuntu.22.04-arm64v8) and checked /license/status:

• Fresh volume: AGPL until the first database is created, then the bundled license. Still licensed after a restart.
• Volume initialized by ravendb/ravendb:6.2.18 with a database: the bundled license is applied at startup. Without this change, the same volume stays AGPL indefinitely.
• Same unlicensed volume with RAVEN_License_Path pointing to a missing file: the container exits with code 255 and the error The RavenDB server cannot start due to a missing license.

I also ran the same scenarios against the published 6.21.3 image with the setting passed as an environment variable. Once applied, the license stays on the volume when the container is later started without the setting.

CI's container-test jobs exercise the full compose stack against the image built from this branch.

Documentation

The RavenDB containers page gains a troubleshooting section for this case in Particular/docs.particular.net#8609. If this PR ships, that section should name the fixed version and only apply to earlier versions.

[andreasohlund]

@mauroservienti @ramonsmits not sure if the scenario is common enough to fix this, but we had a user today affected by this

[ramonsmits]

@mauroservienti @ramonsmits not sure if the scenario is common enough to fix this, but we had a user today affected by this

Seems like an ok change as we would always have a valid license. Only concern here is that when a user currently has misconfigured the container and updates to this version it seems it could fail to start.