Install Profile System Setting

Overview

The install_profile system setting controls which major feature sets are active and visible within the platform's user interface and API surface. It allows an operator to tailor the system's behavior for specific use cases by selecting one of three predefined profiles.

This setting is designed to be changed at any time by an operator via the Settings UI. Unlike some system settings which are one-way, changes to the install_profile are bidirectional. The setting is configured on a per-tenant basis, allowing different tenants to use different profiles.

How It Works

The system determines the active feature set by reading the install_profile key from the s2r_system_setting table in the database.

Value Resolution and Caching

To minimize database load, especially on endpoints that are checked frequently, the resolved profile is held in a 30-second, in-memory, per-tenant cache. When a setting is updated, the corresponding cache entry is invalidated to ensure the change takes effect promptly.

The resolution logic is as follows:

flowchart TD
    subgraph "Profile Resolution"
        A[Request for tenant's profile] --> B{Cache has value for tenant?};
        B -- Yes --> C[Return cached value];
        B -- No --> D[Read 'install_profile' from database];
        D --> E{Value found and valid?};
        E -- Yes --> F[Normalize value];
        F --> G[Store in cache (30s TTL)];
        G --> H[Return normalized value];
        E -- No --> I[Use default value "both"];
        I --> G;
    end
    C --> Z([Active Profile]);
    H --> Z;

1. The system first checks a tenant-keyed cache for the profile.
2. If the cache is empty for the requesting tenant, the system queries the database for the install_profile setting that applies to that tenant. The system respects tenant-specific values that overlay the platform-wide default.
3. The value from the database is trimmed and converted to lowercase for normalization.
4. If the normalized value is one of the valid profiles, it is stored in the cache and returned.
5. If the database row is missing or contains an invalid value, the system defaults to both. This default is then cached and used for subsequent requests within the 30-second cache window.

F5 Feature Availability

The system uses the f5Enabled() internal check to determine if F5-related features should be available. This function returns true if the current profile is f5_modernization or both.

Available Profiles

The install_profile setting accepts one of three string values. The default for new installations or for tenants without a specific setting is both.

Configuration

An operator can modify the install_profile for the platform or for a specific tenant at any time through the platform's Settings UI. The change is applied after the internal cache expires or is invalidated, typically within 30 seconds.

API Behavior

When the install_profile is set to generic_soap_to_rest, any API request made to an F5-specific endpoint is rejected. The platform will respond with:

• HTTP Status: 403 Forbidden
• Error Code: S2R-ADM-0F5

This is an intentional restriction to enforce the selected feature set.

Troubleshooting

F5 Endpoints Return 403 Forbidden

If you are receiving 403 Forbidden responses with error code S2R-ADM-0F5 from F5-related endpoints, it indicates that the active install_profile for your tenant is generic_soap_to_rest. To access these endpoints, an operator must change the profile to f5_modernization or both.

Invalid Profile Value in Database

If the install_profile setting is manually set in the database to a value that is not one of the three valid profiles (e.g., due to a typo), the system will ignore the invalid entry and default to using the both profile. This will enable all features, which may not be the intended configuration.

All SOAP-to-REST docs