In some cases, Salt states fail to be applied on routers after an upgrade to 5.6.16+, 6.1.12+, 6.2.8+, and 6.3.x-r2+. This will impact any salt states that rely on the CentOS
name to detect or conditionally perform operations on the SSR.
For example, the following top.sls
would be impacted:
base:
'*':
- dummy
'os:CentOS':
- match: grain
- centos_example
Issue ID: PLUGIN-2776
Last Updated: 2024-11-06
Introduced in SSR Version: 5.6.16, 6.1.12, 6.2.8, 6.3.x-r2
Impacted Plugin version: 128T-sip-alg-4.0.1 and below
Problem
The SSR is migrating the underlying Linux distribution in an effort to remain agile and to reduce the surface area of CVEs.
Because the OS version is now reported as Oracle Linux
instead of CentOS
, there is an impact to the SIP ALG plugin, as well as any packages that may have an OS dependency, such as SaltStack.
Once a router is upgraded to SSR version 5.6.16+ or 6.1.12+, the 128T-SIP-ALG plugin version 4.0.1 (or earlier) is impacted by this issue. To avoid this issue, the plugin must be upgraded to 4.0.2 before upgrading the SSR.
For customer deployments implementing custom salt states that leverage OS-specific salt grains for CentOS Linux 7
, those salt states may fail to apply after upgrading to 5.6.16+ and 6.1.12+.
Please see the workaround for steps to determine whether your environment is impacted and to remediate the issue.
Release Notes
- Resolved the salt state issues for the SIP ALG plugin.
- Use the Workaround procedure below to scan salt states prior to Conductor and Router upgrades.
Severity
Details
The potential impact of a software defect if encountered. Severity levels are:
- Critical: Could severely affect service, capacity/traffic, and maintenance capabilities. May have a prolonged impact to the entire system.
- Major: Could seriously affect system operation, maintenance, administration and related tasks.
- Minor: Would not significantly impair the functioning or affect service.
Major
Status
In Progress
Resolved In
128T-sip-alg-4.0.2
Product
SSR Routers
Functional Area
SaltStack
Workaround
Details
Juniper may provide a method to temporarily circumvent a problem; workarounds do not exist for all issues.
Salt states are configuration files used to deploy and manage extensible behaviors on the SSR routers via the salt-minion. They are used by the product to implement certain features, by plugins, and in some cases, to implement customer specific use-cases not otherwise supported by the SSR.
For customers that implement custom salt states, use the following procedure to scan your salt states and identify issues that could arise during or after an upgrade.
-
Log in to the Conductor CLI as the admin user.
-
Enter the linux shell; type
shell
to suspend the CLI. -
Run the following command to scan the custom salt states for
Centos 7
:grep -riE 'cent[-]?os' /srv/salt
-
If the above command returns no hits, none of the custom salt states leverage the OS specific salt grain features.
There exists a possibility that a custom salt state is impacted despite the scan returning an empty result. In this case, please contact your Juniper support representative for support on the matter.
-
If the above command results in non-empty output, remediate the salt states to be OS agnostic.
The exact changes will depend on the business logic of the salt state. Customers should work with their subject matter experts to properly remediate and test any changes.
Example Remediation
Salt state found during scan:
{% set defaults = salt['grains.filter_by']({
'CentOS Linux-7': {
'network_routes_target_filedir': '/etc/sysconfig/network-scripts/route-',
},
}, grain='osfinger', merge=salt['pillar.get']('repo_map:merge'), base=None) %}
The remediated salt state:
{% set defaults = {
'network_routes_target_filedir': '/etc/sysconfig/network-scripts/route-',
}
%}