v10.34.2

Configuration editor guidance

Radiator UI now offers more relevant suggestions and explanations as you write configuration, including nested settings and context variables.

AAA log column order

AAA log views now show fields in the same order as their log configuration, making custom log layouts easier to scan.

Certificate upload preview

Radiator UI shows a selected certificate's identity, validity dates, and alternative names before it is saved, making it easier to confirm the right file was chosen.

Documentation search

Find configuration references alongside articles and log messages when searching for a protocol such as TACACS+.

Package upgrades and removal

See the Package upgrades and removal article for the tested upgrade paths of the Radiator Server Linux packages, and for the files that an upgrade, a removal, or a purge keeps or deletes.

ZIP and tar.gz configuration archives

Radiator UI can import configuration and template archives in either format. Choose ZIP or tar.gz when exporting configuration, templates, or a stored backup. You can also restore a downloaded backup archive to the pending configuration for review before deployment. ZIP remains the default for existing API clients.

On Unix systems, tar.gz archives also retain file and directory permissions when imported. Exported tar.gz archives record the owner and group of each file and directory as well.

See Configuration Import and Export for the archive options and restore steps.

Management session authorization cache

Successful management logins now store a sanitized server-side authorization snapshot for cookie-authenticated UI and API requests. Fresh sessions avoid repeating external group and privilege lookups, while stale snapshots are refreshed once per session even when several requests arrive concurrently. Basic Auth credentials are still verified on every request. Failed refreshes briefly pause backend retries to reduce repeated requests during outages. When the identity backend no longer authorizes a user, the refresh removes the session, so revoked privileges take effect within the cache lifetime.

The fixed, non-sliding cache lifetime defaults to one minute and can be changed or disabled with resolve_cache_timeout in the management HTTP configuration. See the management configuration documentation for the cache-aware http_management_authentication block syntax. Adopt this block to enable caching in existing installations. The block requires both an @resolve pipeline that loads the user and an @verify pipeline that checks the credentials; use @verify { http_basic_auth; } to compare the submitted password with the password loaded by @resolve. Existing http_management_authentication; statements and the legacy credentials block remain supported without authorization caching. Restarts that preserve management sessions discard cached authorization, so the first request refreshes it.

RadiatorDB Startup and Maintenance

RadiatorDB now sets up PostgreSQL nodes in the background. An unavailable node no longer prevents Radiator Server from starting. Nodes that have completed setup can serve requests while other nodes wait for a connection or recover. Temporary connection failures retry automatically. Existing configurations require no changes.

Radiator UI now shows cluster availability, node setup and health, and replication status in the RadiatorDB maintenance view. You can inspect node storage and replication resources, download or import backups, and remove or reprovision a node that needs repair. Remove Node deletes RadiatorDB data on that node and its replication connections with peers. The node remains in the configuration; remove it from RadConf before restarting Radiator Server if you do not want it provisioned again.

Each node setup attempt has a 30s timeout by default. Increase setup_timeout if a larger initial copy needs more time:

radiatordb "MAIN_DB" {
    setup_timeout 2m;
}

See the RadiatorDB installation guide for deployment and recovery, and the RadiatorDB configuration reference for setup and health-check settings.

Find service logs from the dashboard

The Services panel now makes counter details and logs easier to distinguish. Log shortcuts open a relevant log view with the service search applied, and switching log tabs keeps the search text.

Filter dashboard traffic by category and service

The Traffic card provides separate views for servers, handlers, policies, backends, and management traffic. It shows which traffic contributes to the totals, supports one-click service focus, and distinguishes unavailable data from no activity. Filters persist across page reloads. The All view excludes accounting by default; it can be included from the filters. Each total explains what it includes.

Browser Security Headers

Radiator UI and the management API now send headers that reduce browser risks from framing and unsafe content loading. HTTPS listeners require HTTPS for the host and its subdomains for 1 year by default. Ensure services on those names support HTTPS. Set strict_transport_security false; to disable the header, or true; to send it through an HTTPS-terminating proxy. See the management configuration reference.

Deployments during recovery mode

Configuration deployments can now restart a server in recovery mode without ending the current Radiator UI session, even when the deployed configuration does not resolve the recovery condition.

System dashboard metrics

The System card now shows CPU, memory, and pipeline readings beside larger trend charts. Select a metric to open its corresponding counters.

Radiator UI outage recovery

Radiator UI limits repeated requests while Radiator Server is unavailable. It refreshes displayed data and resumes live updates when the connection returns.

Log row markers

Right-click a row in a Radiator UI log table and select Add marker here to see which entries are logged after it while logs stream. A labeled line separates the marked row from the newer entries. Markers are visible only in your browser and are removed when you reload the page. See Logging.

Accurate gauge charts

Counter details charts now average gauge samples within the selected time interval. Values such as process memory stay on the right scale as the interval changes, and periods without samples remain empty. No operator action is required.

Sign-in with existing browser data

Radiator UI now accepts a new login when the browser retains an older session cookie for the same site.

HMAC-SHA2 RadConf filters

The hmac_sha256(key), hmac_sha384(key) and hmac_sha512(key) filters generate keyed signatures with 32-, 48- and 64-byte output respectively. Append hex or base64_encode for text output. See the filter reference.

One use case is generating stable RADIUS Chargeable-User-Identity values from an authenticated identity. See Chargeable-User-Identity for a configuration example.

Quieter minimum-connection maintenance logs

Configurable EAP-MSCHAPv2 password retries

The eap_mschapv2 method now accepts max_password_retries in RadConf, with values from 0 to 255. Set max_password_retries 0; inside the block in the eap action to reject the first incorrect password without offering an interactive retry. This can prevent unattended clients from waiting for replacement credentials.

The default remains one retry after the initial attempt, so existing configurations retain their behavior. The setting also applies to inner EAP-MSCHAPv2 in PEAP, TTLS with inner EAP, and TEAP. It is available only through RadConf and is not exposed through the management API.

See EAP-MSCHAPv2 password retries for configuration details.

Named and shared dashboard presets

The Radiator UI dashboard's Customize menu now lets users choose between named dashboards. Every user starts with the built-in Default dashboard, which cannot be changed; saving changes to it creates a personal copy. Personal dashboards can be renamed, duplicated, rearranged, and deleted. Radiator UI remembers which dashboard each user last selected.

Dashboard changes are now explicit. Adding, removing, reordering, and resizing widgets and charts, or changing the time range, creates unsaved changes that Customize offers to Save or Cancel. Nothing is stored until Save.

Users with the write management privilege can turn on Share with all users for one of their dashboards. The dashboard moves to every user's selector rather than being copied, and the user who shared it is shown as its owner. Users without the write privilege can view shared dashboards and save changes as their own copy, while users with it can edit them, and everyone sees the latest version. If two users edit the same shared dashboard at the same time, the later save is rejected instead of overwriting the earlier one. Turning sharing off returns the dashboard to its owner as a personal dashboard; anyone else who turns it off is warned that they lose access. Deleting a shared dashboard removes it for everyone.

In the metric explorer, Add to dashboard now asks which dashboard receives the chart. A chart opened from a dashboard can be saved back to that dashboard when the user is allowed to change it.

Existing dashboard customizations are kept as the personal dashboard My dashboard. Shared dashboards are stored with the UI settings in the configuration directory, so configuration exports, imports, and backups that include UI settings also include them. The management API provides /api/v1/ui/shared/dashboards for listing, sharing, unsharing, and deleting shared dashboards.

See Management API privileges for the privilege levels.

jsonfile result pipelines

The backend action can now call jsonfile queries with @each and @once pipelines, the same way as RadiatorDB queries. The new jsonpath "<expression>" query statement selects the results, and the pipeline processes them one at a time with the current result available as item. See Selecting results with jsonpath.

• @once rejects when the jsonpath expression matches zero values or more than one value, so a user lookup cannot silently match several entries.
• @each rejects when the jsonpath expression matches no values.
• The mapping block is now optional.

Implementation-agnostic callers

The query mapping block runs for each result before the @each or @once pipeline. Map the JSON fields to variables such as vars.username in the query, and read only those variables in the pipeline. The calling pipeline then does not need to know the JSON file format or use the jsonpath filter, and a change to the file format requires updating only the query mappings.

query "FIND_GROUP" {
    jsonpath "$.users[?(@.group == $args.group)]";
    mapping {
        vars.username = item | jsonpath("$.username");
    }
}

backend {
    name "USERS";
    query "FIND_GROUP";
    args {
        group = "staff";
    }
    @each {
        vars.staff_users += vars.username;
    }
}

Deprecated mapping argument

The mapping "<jsonpath>" argument is deprecated and emits a deprecation warning. Replace it with a jsonpath "<expression>" statement and a plain mapping block; the mappings run for each matched value in the same way. The @each and @once pipelines are rejected for queries that still use the mapping argument.

Assignments to single-value targets

Assignments can now assign a filter chain or other multi-value expression to a single-value target such as user.username when the expression produces exactly one value. The assignment fails with a descriptive error when the expression produces several values.

Linux packet capture

Radiator Server can now capture actual packets sent and received on Linux network interfaces. Configure Linux packet capture to select traffic and save it in PcapNG format for analysis with Wireshark.

EAP-TLS final handshake delivery

Radiator Server now delivers the final TLS handshake records before completing EAP authentication. This fixes an intermittent EAP-TLS failure observed with TLS 1.2 after changing TLS session cache settings and reloading configuration.

An affected supplicant could receive Access-Accept and EAP-Success, then report CTRL-EVENT-EAP-FAILURE EAP authentication failed and EAPOL: EAP key not available. The server accepted authentication while the client could not complete its TLS handshake.

No configuration changes are required. See EAP-TLS handshake logging for the server's handshake and fragment log fields.

Outbound TLS certificate expiry checks

Enable check-local-certificate-expiry in an outbound connection's RadConf tls block to block attempts with expired local certificates:

tls {
    check_local_certificate_expiry true;
}

Checking defaults to disabled, preserving existing connection behavior. When enabled, certificate-expiry-grace-period defaults to 0s. Configure a positive duration to allow attempts within that time after expiry. An allowance alone does not enable checking.

Separate diagnostic messages identify blocked attempts and attempts allowed with expired local certificates. Peer certificate verification continues to apply.

Logging context in AAA logs

Use clog.fields and clog.namespace to include the active logging context's fields and namespace in AAA logs.

See Execution Context.

Configuration File Permissions

On Unix systems, Radiator now applies default permissions to new configuration files and directories that it creates through uploads, pending configuration operations, deployments, and configuration or template archive imports:

• New files are created with mode 640. Group members can read the files, and only the owner can modify them.
• New directories are created with mode 2770. The setgid bit makes files added later inherit the directory group.

Existing files and directories keep their current permissions, for example when a file is uploaded or saved again.

ZIP archives do not store Unix permissions, so every file that a ZIP import writes receives mode 640, also when it replaces an existing template or license, and directories that it creates receive mode 2770. tar.gz archives continue to keep their stored permissions, including the setgid bit on directories, but setuid, setgid, and sticky bits are not restored on files. Copied, restored, or deployed files keep the permissions of their source files.

This makes configuration content easier to manage on packaged Linux installations where Radiator Server runs as the radiator user and group.

Clearer configuration import of missing directories

When an archive does not contain a content directory, such as lua/, the import dialog in Radiator UI marks the directory as not in the archive and leaves it unchecked, so the existing content is kept. If you check it anyway, the import preview shows how many existing files the import removes. Directories without existing files no longer produce a warning. See Configuration Import and Export.

RADIUS accounting with Message-Authenticator enforcement

Valid RADIUS accounting requests are now accepted when the client has require_message_authenticator true. Authentication requests continue to require Message-Authenticator.

Accurate available memory on Linux

On Linux, stats.system_mem_available_bytes and the Prometheus metric radiator_system_memory_available_bytes now report the memory that new allocations can get without swapping. Earlier versions reported only unused memory, which leaves out page cache and is low on most hosts.

Both values read higher than before. If you compare them against a threshold, for example in a health check or an alert rule, review the threshold.

See stats Context Variables.

Expiry overview and expired certificate clean-up

The dashboard shows one badge for everything that expires soon: certificates and CRLs used by the running configuration, license expiry and the end of license upgrade eligibility. Click the badge to see each item and open the file or page where you can replace it.

The configuration file list marks certificate and license files that expire within 90 days, and certificate template forms show the validity of each stored certificate file. Deleting a stored certificate or key file in a template form now asks for confirmation and names the configuration entries that still use the file. Delete expired removes all expired certificates in a list at once. See Configuration Editor.

New RadConf configuration parser

Radiator Server uses a new parser for RadConf configuration files. The following changes can affect existing configurations.

Breaking: quote password_hash() and yubikey() keywords

A bare name in a filter argument is now a local variable reference. Unquoted yubikey() and lowercase password_hash() keywords still work but are deprecated. Any other bare name, such as password_hash(PBKDF2-SHA512) or the misspelt yubikey(pasword-otp, otp), loads without an error and fails on every request. Quote every keyword argument:

password_hash("pbkdf2-sha512")
yubikey("password-otp", "otp")

Filter arguments can now also be expressions, such as password_hash(vars.algorithm). See yubikey() and password hashing.

Undefined environment variables in HTTP backends

These options are now evaluated per request, so an undefined env.* variable in them is no longer reported when the configuration loads:

• http backend url and query path
• authentication basic username and password
• authentication oauth2 token_url, device_url, client and secret

Use default() for optional variables, for example url "https://%{env.API_HOST | default("api.example.com")}/v1";.

New deprecation warnings

The following syntax still works but now logs a deprecation warning:

Release builds log deprecation warnings only when RADIATOR_SHOW_DEPRECATIONS=1 is set.

Configuration backup retention

Configuration deployments no longer keep every backup forever. After each successful deployment, Radiator Server removes the configuration backups that are older than 90 days, except the newest 10. Backups created by cluster deployments are included.

Change the limits with the backups block in the management block:

management {
    backups {
        keep 10;
        max_age 90d;
    }
}

The first deployment after upgrading applies these defaults to the existing backups. To keep every backup, add this block to the configuration before you deploy. The settings apply to the deployment that contains them:

management {
    backups {
        keep 0;
        max_age 0s;
    }
}

To delete a single backup, open Restore from Backup in Radiator UI and use the delete action of the backup.

See Configuration Backups.

Certificate and license expiry warnings

Certificate and license expiry warnings in Radiator UI now start 90 days ahead and turn red within 30 days. The certificate details shown when you upload certificate files, one or several at once, now include these warnings for each certificate in each file. Connection details, the Licenses page, and the dashboard use the same thresholds. See Configuration Import and Export and Getting a Radiator License.

License upload preview

When you select a license file on the Licenses page, or upload .license files in Configuration -> Files, one or several at once, Radiator UI now shows the licensee, license type, serial number, validity dates, and licensed services before the file is uploaded. For a perpetual license it also shows the build date through which upgrades are covered, with the same eligibility warning as the Licenses page service status. A license that expires soon, or whose upgrade eligibility ends soon, is highlighted but can still be uploaded.

Radiator UI does not upload a file that is not a valid license, or a license that Radiator Server would reject, for example because it has expired or duplicates the serial number of an installed license or of another license selected for the same upload. The reasons are listed in the dialog for each license file, so a bad license no longer causes the next configuration deployment to fail. If an upload fails, the Licenses page now shows the error. See Getting a Radiator License.

Keep me signed in

The Radiator UI sign-in form has a Keep me signed in option. It is selected by default, which keeps the previous behavior: the session continues after the browser restarts until it expires. Clear the option, for example on a shared computer, to end the session when the browser closes. The browser remembers the last choice. The configured session timeouts apply in both cases. Administrators can remove the option and end every session when the browser closes with allow_keep_signed_in false; in the management.http block. See Session Timeouts.

Diagnostics package for Radiator support

Radiator UI can now download a diagnostics package from the account menu on any page. The package is one tar.gz archive with the active configuration, all application and AAA logs held in memory, and a summary of the server version, uptime, resource use, and licenses. Configuration files keep their modification times, permissions, and owners, which helps support find editing and file access problems.

The package is not sanitized: it contains private keys, credentials, and logs with user data. Downloading it requires the read privilege.

See Diagnostics Package.

CPU and memory peaks

Radiator now samples process CPU and memory every 5 seconds and keeps the lowest and highest sample of each statistics interval. The Peak values on the Radiator UI System card include short spikes, and the CPU reading shows the latest sample. The CPU and memory charts on the System card and in the counter details show a shaded band between each interval's lowest and highest sample, and their tooltips show the minimum, average, and maximum. The Pipelines chart shows a band from the median to the slowest request around P95, and Max shows the slowest request. Spikes remain visible in the 24-hour and 7-day views. See statistics.

Hyphen- and dot-numbered configuration files load in numeric order

When Radiator Server loads a configuration directory, the leading number of each file and directory name controls the load order. A number now ends at _, -, . or the end of the name. Earlier versions recognized only _, so names such as 10-clients.radconf, 10.radconf or a 20-policies/ directory were unnumbered and loaded after all underscore-numbered files.

For example, a directory with these files:

10-example.radconf
23_policies.radconf
90-extra.radconf
100-extra.radconf

now loads them in the order 10-example, 23_policies, 90-extra, 100-extra. Earlier versions loaded 23_policies first and the rest in text order: 10-example, 100-extra, 90-extra.

Names in which the digits are followed by another character, such as 10abc.radconf, are still unnumbered.

Compatibility: files merge in load order, so the new order can change the effective configuration of an existing installation, for example which definition wins or which pipelines are available to later files. Radiator Server does not warn about the changed order.

How to migrate

1. Before or after upgrading, look for configuration files and directories whose names start with digits followed by - or ., such as 10-example.radconf, 10.radconf or 20-policies/.
2. If you find any, check that the configuration works as intended in the new numeric order.
3. To keep the earlier order instead, rename them so that they sort as before: give them _-numbers higher than every other numbered name, in the order they loaded before. In the example above, rename 10-example.radconf, 100-extra.radconf and 90-extra.radconf to 30_example.radconf, 31_extra.radconf and 32_extra.radconf.

See Configuration directory load order for the complete rules.

Configuration file details

Choose Details for a configuration file or directory in Radiator UI to see its size, timestamps, permissions, owner and group, and whether it differs from the active configuration. For .radconf files, the details show the load-order position. For files, they also show the SHA-256 checksum and the template the file was generated from. Radiator UI points out files with permissions more permissive than 640 and directories with permissions more permissive than 2770. File contents are never shown. The HTTP management API provides the same information at GET /api/v1/configuration/file-details/{path}.

Configuration warnings in Radiator UI checks

The syntax and full configuration checks in Radiator UI now show configuration warnings. Previously, these warnings appeared only in the application log after the configuration was deployed.

Warnings are listed with their file and line in a compact, scrollable list grouped by file, and warnings in the open file are marked in the editor. Warnings do not fail a check or block deploying. After deploying, the deployment notification shows the warnings of the deployed configuration, also when deployment conflicts were resolved.

Deprecated settings are counted in the check result and listed on a new Configuration notices page, opened with Review configuration notices in the Files page menu, grouped by message with their suggested replacement and links to each file and line.

See Configuration Warnings.

Explicit management listeners and TLS warnings

Management listener requirement

An enabled management block now requires an explicit listen block inside http. Previously, omitting the listener opened plaintext HTTP on 0.0.0.0:8080. Rejecting this configuration prevents accidental exposure of Radiator UI and the management API, including credentials sent over plaintext HTTP. This security change intentionally breaks configurations that relied on the implicit listener.

Before upgrading, configure the intended protocol, address, and port. For HTTPS, include a tls block using your configured certificate and key references:

management {
    http {
        listen {
            protocol tcp;
            addr 127.0.0.1:8443;
            tls {
                certificate "MGMT_CERT";
                certificate_key "MGMT_KEY";
                require_client_certificate false;
            }
        }
    }
}

To disable HTTP management, omit management or set no http; inside it. no ui; alone still leaves the management API enabled and requires a listener. See management listener configuration.

TLS configuration warnings

For management, RADIUS, HTTP, and TACACS+ stream listeners, a tls block on a TCP listener enables encryption. Redundant TLS protocol selection is now deprecated. Existing TLS declarations remain accepted; declarations without TLS settings produce a WARN message stating that traffic uses unencrypted TCP.

See listener TLS settings and management TLS settings.

Configuration supporting files

Radiator Server silently ignores dpkg, RPM and ucf backup and staging entries during configuration discovery. Other unknown file suffixes still produce warnings.

Radiator UI renders .md files, including Mermaid diagrams, and supports editing their source.

See Configuration directory load order and Markdown files.

RadConf context references in JSONPath

JSONPath filters and JSON file backend queries now accept RadConf accessors prefixed with $. References read values from the surrounding execution context and insert them as literal values with automatic quoting and escaping.

For example, select a user entry by its object key:

query "FIND_USER" {
    jsonpath "$.users[$aaa.identity]";
}

[!WARNING] aaa.identity can contain unauthenticated, client-controlled input. Interpolating %{aaa.identity} into a JSONPath expression enables JSONPath injection: quotes or backslashes can change the query and select another user's record, including password or group fields. Replace interpolation with an unquoted $aaa.identity reference.

Migrate %{...} interpolation of request values to unquoted $accessor references. An absent reference makes the whole query return no matches and logs the missing accessor.

See JSONPath for query examples and migration guidance.

Native 64-bit integers in Lua scripts

Radiator Server upgrades its Lua scripting runtime to Luau 0.740 with native signed 64-bit integers. Scripts can preserve large identifiers and counters without rounding, including integer fields inside JSON.

Use the new radconf.get(path) and radconf.set(path, value) functions to read and write variables with full signed 64-bit precision. Write integer literals with an i suffix and use the integer library for arithmetic:

radconf.set("vars.record_id", 9007199254740993i)
local id = radconf.get("vars.record_id")[1]
radconf.set("vars.next_record_id", integer.add(id, 1i))

Ordinary Lua numbers remain floating-point values and cannot represent every integer beyond 9007199254740992. Existing context fields and methods keep their numeric behavior for compatibility. Move variable reads and writes to radconf when your script needs exact large integers. Existing scripts and require() module loading continue to work.

The radconf API also exposes RadConf filters as chains. Use radconf.filter(value) for a supplied value or radconf.filter.variable(path) to start from a variable and retain its path for writing the result back. For example, normalize the identity to lowercase:

radconf.filter.variable("aaa.identity")
    :lowercase()
    :assign()

Filtering leaves the source unchanged until :assign() is called. Use :value() to retrieve a single result or :values() to retrieve all results.

See variable access, filter chains, and value conversions for details.

Fairer backend load balancing and failover

RADIUS round_robin server selection now rotates the starting server for each new request. Retries continue through the remaining servers without changing the next request's starting position.

RADIUS least_outstanding connection selection now rotates among connections with the same lowest load, including idle connections. This spreads light, sequential traffic across warm connections and reduces avoidable idle disconnects.

With least_connections, RADIUS, PostgreSQL, MySQL, LDAP, and RadiatorDB now rotate among servers with equal loads and priorities. Configured priorities still take precedence when loads are equal. Diameter peer groups also rotate among peers with the fewest pending transactions. Retries continue cyclically after the last attempted peer, with lower loads taking precedence for least_connections. Failover does not advance the rotation for new requests.

RADIUS failover no longer revisits servers already attempted for the same request. DNS-discovered RADIUS backends can try all discovered servers.

HTTP server selection and persistent connections

HTTP backends support named servers with all server selection policies for load balancing and failover.

The HTTP idle connection timeout is now configurable.

Existing configurations remain valid. For frequent idle disconnects, compare the server idle timeout with the expected traffic gaps on each connection, especially when the requesting peer keeps multiple connections open.

See backend load balancing, RADIUS connection selection, Diameter peer group selection, and RADIUS idle timeout guidance.

HTTP response header controls

Configure default_headers in an HTTP server block to add response headers, such as Cache-Control: no-store. Explicit response headers take precedence over these defaults.

Set populate_aaa_headers false; to disable automatic X-AAA-* response headers.

RadiatorDB Forced Node Removal and Collection Maintenance

Remove Node in the RadiatorDB maintenance view of Radiator UI can now force remove a node that is down or whose replication is broken. Removing a collection from the configuration no longer stops RadiatorDB setup; its data is kept until you destroy it in the same view. Failed node setups and removals explain which step failed.

A newly configured collection becomes available only after every configured node has been set up. Callers of the garbage collection API must switch to /internal/backends/radiatordb/{db}/gc.

See RadiatorDB maintenance.

Experimental alerts and backend incidents

An alerts block enables experimental alerts on metrics and warning or error logs, and tracks backend failures as incidents until the backend confirms recovery. Radiator UI then shows the results on an Alerts page. Without an alerts block, Radiator Server behaves as before. The feature may change in later releases.

See Alerts.

Resizable editor file tree

The file tree beside the Radiator UI configuration editor is wider by default, and dragging the handle between the tree and the editor resizes it, so long filenames can be shown in full. Filenames are shortened only when the tree is narrower than the name. The handle also works from the keyboard with the arrow keys, Home and End, and double-clicking it restores the default width. The chosen width is saved with the user's other Radiator UI settings.

Exact configuration check locations

Configuration check errors and warnings show their file, line and column, and the editor underlines only the affected text. The deploy dialog describes what each option does.

Change markers in the configuration editor

The configuration editor in Radiator UI marks lines that differ from the active configuration. Clicking a marker shows the change and can revert it. See Configuration Editor.

Permission notices in Radiator UI

Pages that need a higher management privilege now show a notice naming the required privilege, with links to the pages the user can open, instead of error notifications. Users without dashboard access, such as users who only work with RadiatorDB databases, see this notice after signing in.

Linux-only releases

Radiator is no longer built or published for macOS or Windows. Install it from the Linux packages or run the container images instead.

TCP Keepalive for HTTP Connections

HTTP and management HTTP listeners now apply their configured TCP keepalive settings. Set idle, interval, and count in every keepalive block. See keepalive.

Policy selection stops at the first matching policy

Radiator Server now processes a request only with the first policy whose conditions match. If no handler in that policy matches, request processing stops and Radiator Server no longer tries the next policy. This restores the policy selection behavior from before version 10.32.1.

If your configuration relies on falling back to a later policy, move the distinguishing conditions from the handlers to the policy conditions or add a catch-all handler to the earlier policy. See policy selection.

Typed RadiatorDB Where Filters and Result Order

RadiatorDB query where blocks can now filter with >, >=, < and <=, and != accepts regex literals. Comparisons follow the declared field type, so numbers compare numerically, datetimes compare as points in time regardless of their offset, and hex values match in any letter case. Queries can also order their results by a declared field with order_by and return only the first results with limit, for example to find the next user to expire.

Check Existing Queries

Typed comparison changes the outcome of some existing where filters:

• == and != on list fields fail. They previously compared the JSON text.
• == and != with a plain string on ip and network fields test containment instead of text equality. On network fields, the stored network must contain the whole CIDR value. On ip fields, a CIDR value shorter than a host prefix fails.
• A value without a single value to compare, such as a missing attribute, a JSON null, array, or object, a failed expression, or a masked password, fails the request instead of matching the text null.
• A request value that does not fit the field type fails the query, except an unknown enum option, which matches nothing.

When collection is a literal, filters on undeclared fields, unsupported operators, and literal values that do not fit the field type fail at startup. With an expression collection, they fail when the query runs. Radiator also fails at startup when a query or put uses a literal collection that the backend does not declare, when a literal where value can never be compared, such as none, even with an expression collection, and when a literal limit is invalid.

Document Cursors

The RadiatorDB document lists of the HTTP Management API, including the maintenance document list, answer an invalid cursor with a 400 response that explains the problem. Cursors from earlier Radiator versions are no longer accepted; restart pagination without the cursor.

See Where clause, Result order, and RadiatorDB REST API.

Experimental Active Directory authentication over Netlogon

The new experimental netlogon backend authenticates MSCHAP and MSCHAPv2 users directly against an Active Directory domain controller over an AES-protected Netlogon secure channel. The feature may change in later releases.

See Netlogon backend.

Nested condition blocks

The all, any and none condition blocks can now contain other condition blocks. One condition can express any combination of rules, such as matching either of two users in different groups, without repeating policies, handlers or if actions. See condition blocks.

URL-safe encoding, request cookies and per-request bearer tokens

New sha256, base64url_encode and base64url_decode filters support OAuth 2.0 and OpenID Connect values such as PKCE code challenges. HTTP pipelines can read request cookies with http.cookie.NAME, and HTTP backend bearer tokens can now come from the current request.

Single sign-on to Radiator UI (experimental)

Users can sign in to Radiator UI with an OpenID Connect identity provider such as Microsoft Entra ID or Keycloak. The feature is experimental. The management policy maps the provider's groups and roles to Radiator UI privileges, and password sign-in stays available. A provider tls block trusts identity providers whose certificate is issued by a private CA. See Radiator UI Single Sign-On with OpenID Connect.

RadiatorDB Storage Statistics

RadiatorDB now publishes document, tombstone and revision counts as statistics for each node and for each collection on the node. You can see which collection grows without inspecting each collection separately. See Storage Statistics.

RadiatorDB Spelling in the Management API

The management API and its OpenAPI documentation now consistently spell the product name as RadiatorDB, and the documentation is published as OpenAPI 3.1. RadiatorDB document and backup requests and responses are unchanged. Scripts that match RadiatorDb in backend or license responses must match RadiatorDB instead. See the RadiatorDB REST API article.

EAP-TEAP session keys

EAP-TEAP can derive session keys as RFC 9930 defines, which wpa_supplicant 2.12 and newer require. Set session_key_derivation rfc9930; when such peers authenticate but cannot connect. EAP-TEAP over TLS 1.3 now follows RFC 9427. See EAP-TEAP.

EAP-TEAP in radiator-client performance

radiator-client performance can load test EAP-TEAP with inner EAP-MSCHAPv2 or Basic-Password-Auth. It can also authenticate a machine and then the user in one authentication, as Windows does with EAP chaining. See Run EAP authentications.