v10.32.0

Improved Configuration Conflict Resolution

The conflict resolution dialog during pending configuration deployment has been redesigned for clarity and control.

Per-File Resolution

When deploying a pending configuration that conflicts with changes made to the active configuration, users can now:

• Choose per-file which version to keep: the current active version or the pending version
• Backup the discarded version as <filename>.deploy-conflict.bak to preserve changes before overwriting
• Use bulk actions to quickly set all files to the same resolution

Explicit Confirmation Required

The deploy button is now disabled until every conflicting file has an explicit resolution selected. This prevents accidental overwrites and ensures users have reviewed each conflict.

Improved Server Restart Experience After Configuration Deployment

When deploying a pending configuration with the "Automatically restart server after deployment" option enabled, the Management UI now displays a progress dialog that guides users through the restart process.

Previously, after deploying configuration with restart enabled, users would see multiple error toast messages as HTTP requests failed during the server restart period. This created a confusing user experience.

The new restart dialog shows a visual stepper with the following stages:

1. Initiating restart - The restart command has been sent to the server
2. Waiting for shutdown - Polling until the server stops responding
3. Waiting for startup - Polling until the server comes back online
4. Server online - Success state, user is redirected to the login page

MySQL and PostgreSQL JSON column support

MySQL and PostgreSQL backends now support reading native JSON and JSONB column types. Previously, queries returning JSON columns would fail with "unsupported data type 'JSON'" error.

This enables queries that return JSON data directly from the database:

SELECT reply_attributes->'$."Framed-IP-Address"' as ip FROM devices WHERE username=?;

The returned JSON values can be used with the jsonpath filter to extract specific fields, or spread directly to reply attributes.

New Actions and HTTP Status Code Handling

This release introduces two new pipeline actions and improves HTTP server behavior with proper status code mapping.

New discard Action

The discard action allows silently dropping RADIUS or TACACS+ requests without sending any response to the client.

The pipeline execution stops immediately when discard is encountered, and no response is sent to the client.

See discard documentation for details.

New ignore Action

The ignore action continues pipeline execution without setting a result, allowing subsequent actions to determine the final outcome. This can be used to convert accept results back to a neutral state.

See ignore documentation for details.

Default HTTP Server Status Codes

The HTTP server now returns appropriate HTTP status codes based on AAA pipeline results:

• accept: 200 OK
• reject: 403 Forbidden
• ignore: 404 Not Found
• error: 500 Internal Server Error

Custom status codes set using http.status are still preserved.

Default HTTP Response Body

When no custom response body is set, the HTTP server returns a JSON object with:

• result: The final pipeline result as a string (accept, reject, ignore, error, challenge, or discard)
• message: The reply aaa.message if set

Example response body:

{
  "result": "accept",
  "message": "Authentication successful"
}

Custom response bodies set using pipeline actions override this default.

This may be a breaking for configurations that did not set custom HTTP status codes or response bodies explicitly.

Response Headers

The HTTP server also includes custom headers in responses:

• X-AAA-Context-Id: The AAA context identifier
• X-AAA-Result: The final pipeline result (accept, reject, ignore, or error)
• X-AAA-Message: Optional message from the pipeline (when set)

Final pipeline execution after reply

The final stage in AAA handlers now executes after the reply has been sent to the client. This change allows you to perform post-response actions such as logging, cleanup, or triggering external systems without delaying the client response.

New variable: aaa.challenge-message

A new variable aaa.challenge-message has been added for Challenge responses. This separates challenge prompts from regular reply messages:

When the challenge action includes a message, it now sets aaa.challenge-message instead of aaa.message.

See

• challenge action documentation with syntax examples and message handling details
• execution context documentation with the new aaa.challenge-message variable

New Process Statistics API Endpoint

A new HTTP API endpoint GET /api/v1/statistics/process-stats has been added to expose process-level and system-wide statistics. This is useful for performance monitoring and debugging.

Available Metrics

Fields that are not available on the current platform are omitted from the response.

Prometheus Metrics

The same metrics are also exported via the Prometheus endpoint at /api/v1/metrics/prometheus with the radiator_ prefix.

New Radconf Variables: stats.*

Process statistics are now available in configuration expressions using the stats.* namespace. For example: %{stats.process_rss_bytes}, %{stats.system_cpu_count}.

See context-variables.stats for full documentation.

New Lua Script Context: stats

The same statistics are now available in Lua scripts via context.stats.

See scripts.context.stats for full documentation.

Log writes are now batched to improve performance under high load.

Fixed histogram excessive memory consumption

Fixed a memory consumption issue that occurred when recording latency histograms in high-concurrency scenarios, particularly noticeable during repeated failing TLS connections (e.g., RadSec with certificate validation errors).

Impact

Memory usage during sustained error conditions (e.g., failing backend connections) is now stable rather than growing unboundedly. In testing, memory growth under identical conditions was reduced from 300MB to under 10MB.

Known Issues

When the /var/lib/radiator directory has 15_certificates.radconf file, and the file has not been edited once, the rpm package upgrade will show a warning warning: file /var/lib/radiator/15_certificates.radconf: remove failed: No such file or directory. The warning is harmless and can be ignored, as the 15_certificates.radconf file has been renamed.