Set Context Variable fave as String to: banana
Set Context Variable fruits as String to: apple,banana,pear,banana
Split variable fruits into fruitsalad on ","
Look Up Item by Value: find item ${fave} within ${fruitsalad}; output index to ${index}
Return Template Response to Requestor -- ${index}
This fails to return "1,3". However, in the ssg_0_0.log file, a similar INFO entry to the following is logged:
System Administration
Issue:
Gateway node sometimes takes a longer time to boot up after applying a patch.
Workaround:
To improve system reboot time, follow these steps for each Gateway node:
-
Take a snapshot of your VM.
-
Run the following commands in the same order as mentioned below:
# cd /etc/rc.d/init.d
# ./layer7-run-once-on-boot
This command might take a few minutes to execute.
# reboot -n
Your Gateway node boots up quickly. Repeat this task for every node in the cluster.
Gateway version 10.0 supports the CentOS 7 platform. The following are known Gateway issues related to the CentOS 7 platform.
Update my.cnf File to Fix Issue with mysqld Generating Error Logs
Issue:
In Layer7 API Gateway 10.0 OVA installation, mysql error logs are generated in
/var/log/messages
instead of
/var/log/mysqld.log
as defined in the
my.cnf
file.
Reason:
In CentOS 7, systemd manages MySQL server startup and shutdown.
[mysqld_safe]
is not installed as it is not needed. Some parameters are defined in the
[mysqld_safe]
section in
my.cnf
file such as log file path and pid-file. So it might seem like mysqld is not generating error logs.
Workaround:
Edit the
my.cnf
file and move all the content from
[mysqld_safe]
section to
[mysqld]
section. Restart the MySQL server.
Ensure that you overwrite the
pid-file
parameter line. If there are multiple entries in the
[mysqld]
section for a parameter, then only the last line is prioritized and earlier entries are ignored.
AMI Gateways: Network Service Showing a 'Failed' Status
Issue:
AMI Gateway (version 10.0) customers may report seeing a failed status for their network service when viewing the summary of network devices and their connection status:
Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface eth0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth0 does not seem to be present, delaying initialization.
Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: [FAILED]
Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface ssg_eth0: [ OK ]
Workaround:
None required. Due to the
predictable network interface naming scheme
introduced by CentOS 7, the AMI network service will first look for "eth0" when it should be looking for "ssg_eth0", the new name that was given by Gateway. As long as the service is able to verify the existence of "ssg_eth0" with an OK status, no actual system failure will occur despite the initial FAILED status associated with "eth0". (DE441402)
Cloned OVAs Require Manual Patching
Issue:
After cloning a Gateway OVA (version 10.0), the Gateway administrator is unable to SSH into it. Newly deployed clones will have different network adapter hardware addresses, causing the VM to create their own unique network interface names with the predictable device naming scheme. Because of the name conflict between the original OVA and the clone, the firewall rules in the iptables prevents the user from accessing OVA clones via SSH. This issue is known for the Gateway OVA that runs on CentOS 7. (DE441413)
Workaround:
Customers planning to clone Gateway OVAs should do the following:
-
Disable iptables/ip6tables services prior to cloning.
-
After cloning the OVAs, ensure that the interfaces identified in the network configuration files (i.e., ifcg files) are aligned with the interface names that appear in the iptables/ip6tables. You may use the
nmcli
command as part of your reconfiguration. See the following procedure as an example.
To change a device name from ens160 to ssg_eth0 on a cloned OVA:
-
Log into the cloned OVA as a root user in console.
-
List the available connections to the Gateway with the following command:
nmcli connection show
Two connections should be displayed:
-
One connection with a NAME of 'ssg_eth0' without a DEVICE assigned.
-
Another connection with a NAME of 'Wired connection 1' with DEVICE 'ens160' assigned. Your machine/setup may use a different DEVICE name.
-
Delete the connection without a DEVICE assigned (i.e., ssg_eth0) with the following command:
nmcli connection delete ssg_eth0
You may verify the update with the
nmcli connection show
command.
-
Update the connection with the ens160 DEVICE assigned with the following command (use the appropriate DEVICE name that suits your machine and setup):
nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address "$(cat /sys/class/net/ens160/address)" con-name "ssg_eth0" ifname "ssg_eth0"
The connection with the NAME 'Wired connection 1' and assigned DEVICE of 'ens160' is renamed to NAME 'ssg_eth0', but DEVICE is still assigned as 'ens160'
You may verify the update with the
nmcli connection show
command.
-
Reboot the OVA with the
reboot
command and log back into the cloned OVA again as a root user.
-
List the latest connections with the
nmcli connection show
command to verify that the connection with the 'ssg_eth0' NAME is now assigned with the 'ssg_eth0' DEVICE.
-
Turn on iptables.
-
You should now be able to successfully SSH into the cloned OVA.
The Exited Status: What It Means for Gateway-Related System Services
Issue:
Previously, in CentOS/RHEL 6, init scripts were used to start and stop services. Under systemd, these scripts have been replaced with systemd service units; more importantly, the newly introduced 'exited' status is unique to systemd and may cause confusion if you are new to CentOS 7. For example, if you are checking the status of a service and want to know if it's running, you may come across the
Active: active (exited);
status, as opposed to
Active: active (running)
. This usually means that systemd executed the commands specified in the service unit file but cannot verify if the process is actually running because an associated daemon that monitors that process was not found. Because Gateway does not use a daemon, you may see this status when checking or running services in CentOS 7. (DE437214)
Workaround:
None required.
False Warning Messages in Gateway Log
Issue:
The Gateway log contains a warning similar to the following:
WARNING 1 com.l7tech.server.policy.PolicyCacheImpl: 3255: Policy "Google Auth Code Extension" (#d095d9a4c56c975b34c64db5a6741dd0) contains an unlicensed assertion: Unknown assertion: RetrieveOAuth2Token
The RetrieveOAuth2Token assertion is part of the OAuth Toolkit, which requires no special license. Only the standard Gateway license is required. (DE317426)
Workaround:
None required. The RetrieveOAuth2Token assertion is indeed present and functioning normally. The erroneous log message is caused by internal timing issues during the license check stage of Gateway startup. You may safely ignore this log message.
File Permissions After a Restore
Issue:
Some file permissions may not be correctly restored after a Gateway is restored using the
ssgrestore.sh
command. This results in the Policy Manager being unable to connect to the Gateway. (DE221036)
Issue:
Performance and speed of
Manage Roles
may be impacted when many (> 500) custom roles are created, and each role has numerous (200 to 300) permissions. (DE326081)
Workaround:
Avoid excessive number of roles and permissions.
Migration Issue Between Gateways
Issue:
Migration issues may occur after upgrading. Release 9.1 introduces a new "gateway-hazelcast" FIREWALL_RULE. This rule is automatically added to the Gateway upon restart, if it does not already exist. This entity is created with a unique ID per Gateway. If you attempt a bundle import, the mapping for the "gateway-hazelcast" FIREWALL_RULE must be "MapBy:name" to prevent a 409 conflict. (DE211367)
Workaround:
Modify the bundle file that is created during bundle export as follows:
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE"/>
And then modify it as follows:
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE">
<l7:Properties>
<l7:Property key="
MapBy
">
<l7:StringValue>
name
</l7:StringValue>
</l7:Property>
</l7:Properties>
</l7:Mapping>
Cluster Passphrase Is Invalid After Upgrading to Gateway Version 10.1
Issue
: Affects Appliance Gateway 10.1 users. Some users have reported that after migrating to Gateway version 10.1 from 9.4, the cluster passphrase from the source Gateway is no longer valid in the new Gateway. (DE550173)
If the cluster passphrase contains ‘>’, ‘<’, or ‘&’ reserved XML characters, a web service converts them to their respective HTML entity equivalents (i.e., >, <, or &) in node.properties. This conversion occurs prior to the encryption and saving of the passphrase in node.properties. As a result, the decrypted cluster passphrase will not match the original passphrase.
Workaround
: If this issue occurs, use the
SSGCONFIG menu
> 4) Change the Layer7 API Gateway cluster passphrase option to change the actual passphrase containing the ‘>’, ‘<’ or ‘&’ characters.
When prompted to “Enter the cluster passphrase or 'quit' to quit", specify the actual passphrase that includes the characters '>', ", or '&'. If you encounter an incorrect cluster passphrase error, replace the characters with their entity equivalents.
So if the existing passphrase is:
pa$$phrase>
Enter the passphrase with the entity character substitute:
pa$$phrase>
Next, when prompted for the new cluster passphrase, enter the actual ‘>’, ‘<’, and ‘&’ characters as required. This ensures that the correct cluster passphrase is saved as intended in node.properties.