Performing post-upgrade tasks
After upgrading your PingAccess deployment using the upgrade utility or the installer, you must perform several post-upgrade tasks to ensure that the target version works correctly.
About this task
To see details about the upgrade, examine log/upgrade.log
. To see details about the migrated configuration data, examine log/audit.log
.
Steps
-
Review any warnings returned by the upgrade utility and take the actions indicated in the table below.
At the end of an upgrade, the PingAccess upgrade utility or installer records any manual steps that require user intervention both in the command-line output and in
log/upgrade.log
at the WARN level. Information that does not require user intervention is added to thelog/upgrade.log
at the INFO level. -
Review the HTTP requests configuration to ensure the use of the IP source settings is appropriate for the environment.
-
Stop the source version of PingAccess.
-
Start the target version of PingAccess.
Troubleshooting
Warning text | Steps to take |
---|---|
|
This occurs when the 2.1 path prefix contains functionality supported through a Java regex, but not by the wild card support in 3.1. The user must manually migrate the regex to 1 or more path prefixes in 3.1. For example, consider the 2.1 prefix, |
|
The upgrade utility identifies path prefixes in 2.1 that start with |
|
This is the same as the previous setting, but with the requirement being for a case-insensitive path rather than a case-sensitive one. |
|
In 2.1, individual resources can be disabled. In 3.1, only applications can be enabled or disabled. The upgrade utility takes the approach of disabling the application if any related resources are disabled. Check the final configuration and make sure this is the desired outcome. If it is not, the disabled resources need to be deleted, and the application needs to be enabled. |
|
In a 2.1 setup, there might be resource names that accidentally contain a '.', assuming it is a literal '.' rather than part of a regex. For example, any file extension type resources will probably not be escaping the '.'. This message is intended to bring this change in semantics to the user’s attention. This action item will not show up if the user has correctly escaped the '.' character with the '\.' sequence. |
|
This message indicates that multiple resources that use the same virtual host, but a different web session or site must be mapped under the same context root in the same application to preserve semantics. For example, consider the following configuration:
This configuration triggers this error because these resources cannot be grouped in the same application, but they would need to be to preserve the semantics in the internal.example.com address space. This issue could be fixed by using rewrite rules to place Resource C or Resources A and B under a different namespace. For example, use |
|
Step 2.1 allows OAuth rules to be attached resources that use a web session. While this configuration is likely invalid in the first place, it would be possible to include both a PingAccess cookie and OAuth token in requests and PingAccess would apply policy to the requests as configured. In 3.1, however, an application programming interface (API) application and web application are mutually exclusive so the semantics of this particular configuration cannot be preserved. |
|
The upgrade utility checks that the resource order is consistent before and after the upgrade. This message indicates that the resource order from 2.1 does not match 3.1. This is likely due to how context roots in applications are ordered in 3.1. For 3.1, applications are ordered based on their context root, where the longest context root is checked first during resource matching. One way to address this is to review and potentially change the application context root values associated with the virtual host to avoid Uniform Resource Locator (URL) overlaps between applications. |
|
Indicates a misconfiguration in the source version. Check whether you intended to use an identity mapping for the application and associate an appropriate web session or authorization server if necessary. |
|
Indicates a misconfiguration in the source version. Check whether the OAuth rule is necessary to implement the desired access control policy. |
|
Indicates a misconfiguration in the source version. Check whether the OAuth RuleSet is necessary to implement the desired access control policy. |
|
Indicates a resource associated with the application is associated with OAuth rules. This is likely a misconfiguration, and it is necessary to evaluate whether this was intended or not. |
|
Indicates that an availability profile was created for the site during the upgrade. You might want to give the availability profile a more descriptive name. |
|
The /pa context root was allowed as a valid context root in PingAccess 3.0 and is no longer allowed. |
|
The /pa path prefix was allowed as a valid path prefix in PingAccess 3.0 and is no longer allowed. |
|
With PingAccess 3.2, realms moved to the application. The Realm can still be set using the PingAccess admin API interface. With the change in context for how realms are applied, it is necessary to check existing OAuth Groovy rules to ensure that they behave as expected. This message is shown if any OAuth Groovy rules exist in the migrated configuration. |
|
New security headers properties values are not set during an upgrade to preserve the behavior from the source release in the upgrade. If there is no reason not to in your environment, update the |
|
This message applies to the |
|
This message applies to the |
|
If a virtual host has more than one key pair associated with it, only one key pair will be associated with it after the upgrade completes. This message displays to indicate which key pair was used. |
|
If an application’s context root is a reserved PingAccess path, the application will not be migrated. The indicated application will need to be created with a context root that does not conflict with the reserved path. |
|
If a resource path is a reserved PingAccess path, the application will not be migrated. The indicated application will need to be created with a context root that does not conflict with the reserved path. |
|
With changes in IP source header handling, additional options are available to override the headers used to identify the source address. When an agent is involved, the changes in IP source handling might cause the specified rule to not behave as expected. |
|
The upgrade utility attempts to set the |
|
Virtual host names are now case-insensitive. During the upgrade, after making the names case-insensitive, a duplicate virtual host was identified. It will be necessary to either recreate the virtual host with a new name, or to modify the configuration so the proper virtual host is migrated to the upgraded system. |
|
If a virtual host name contains an underscore (_) character, that does not conform to host naming requirements. In this instance, the underscore will be renamed to the string a-z. For example, if a virtual host named my_virtual_host is migrated, the new name will be mya-zvirtuala-zhost. |
|
When an HTTP request rule is migrated from an earlier release of PingAccess, rules that specify a source of Body are not migrated. A Groovy script rule can be used to perform a similar match, but the details of such a Groovy script require administrator intervention. A simple Groovy script rule that would perform a similar function might be: requestBodyContains('value') A script should be constructed that performs additional validation to ensure the rule passes only when desired. A generic match like this could lead to unexpected results depending on what content might be in the request body. |
|
When migrating SSL settings between versions of PingAccess that use different Java Virtual Machine (JVM) or Java Development Kit (JDK) versions, custom settings might not be compatible. If the protocols or ciphers used are not compatible with the target JVM or JDK, this message indicates which settings need to be manually updated. The PropertyName value can be any of the following values:
|
The RuleSet was removed. Please check your policy configuration.
|
These messages might appear if the source PingAccess installation has misconfigured Groovy Rules. This indicates that you are not permitted to add an OAuth rule to an Application of type Web by editing an existing rule set. Groovy or OAuth Groovy rules will not be migrated for the following reasons:
Check the policy configuration. |
|
The upgrade utility supports migrating a rule set containing multiple cross-origin resource sharing (CORS) or rate limiting rules with the same policy granularity. The upgrade utility will generate new action items, indicating that rules were removed from a rule set. These messages indicate that if both rules exist, there is a restriction to a single rate limiting or CORS rule. Please check to confirm that you have applied the correct rule to the policy. |
|
The new cluster config query port is enabled by default for new PingAccess 4.0 installations when running in CLUSTERED_CONSOLE or CLUSTERED_CONSOLE_REPLICA mode. During the upgrade process to version 4.0, the new cluster config query port is disabled. Messages are written to See the PingAccess clustering documentation before enabling this feature. |
|
During upgrades to release 4.0 and higher, the upgrade utility sets the value of |
|
This message appears if new language properties are added between the source and target PingAccess versions and you have added additional language files or modified the en or en_US files. Update any customized files as required. |
|
This message appears if the language properties have changed between the source and target PingAccess versions and you have added additional language files or modified the en or en_US files. Update any customized files as required. |
|
This message appears if the language properties have been removed between the source and target PingAccess versions and you have added additional language files or modified the en or en_US files. Update any customized files as required. |
|
This message appears if the WebSessionManagement has an invalid cookie name. Invalid characters are replaced with an underscore. Update any references as required. |
|
This message appears on upgrade to release 4.3 or later if you have one or more authentication requirements rules. You can make adjustments to configured rules so you can remove this property or you can maintain the property to leave existing rules unaffected. |
|
This message appears on upgrade to release 5.1 or later to support the existing logging behavior of application resource IDs as integers. The default behavior of release 5.1 and later is to log these IDs as strings. You can choose to log application resource IDs as strings after the upgrade by removing, or setting to false, the applicable property in the |
|
This message appears on upgrade to release 5.3 or later if the source version has an application resource that contains a method with whitespace. The resource is preserved by the upgrade, but the method is removed. |
|
This message appears on upgrade to release 5.3 or later if all of the methods associated with a resource were removed with an |
|
This message appears on an upgrade to release 6.0 or later. The runtime state clustering feature has been deprecated. |