4.18.05 Edge for Private Cloud release notes

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation.
info

This section describes version 4.18.05 of the Edge for Private Cloud Feature Release.

Release summary

The following table summarizes the changes in this Feature Release:

New Features ○ JWT Policies are now Generally Available (GA)
○ RedHat Enterprise Linux 6.9 is now supported
○ Oracle Linux 6.9 is now supported
○ CentOS 6.9 is now supported
○ New Edge experience installation configuration changes
○ Router retry options can now be set at the virtual host level
Included Releases
○ Edge UI:
   18.04.04
   18.03.02
   18.02.14
   17.11.06
○ Edge Management/Runtime:
   18.04.06
   18.04.04
   18.03.02
   18.02.02
   18.01.05
○ Portal:
   18.04.25.01
   18.04.25.00
   18.04.23.00
   18.03.28.00
   18.03.05.00
   18.02.15.00
   18.01.31.00
   17.12.20.00
Retirements ○ API BaaS
○ Monitoring Dashboard (Beta)
Deprecations ○ Apigee secure stores (vaults) replaced by KVMs
○ Adding paths on the API proxy Performance tab
○ SMTPSSL property for the Developer Services portal
Bug Fixes ○ Prevent user's email address from being changed (65550638)
○ Security vulnerability in jackson-databind (69711616)
○ Memory leak in Message Processors (71612599)
Known Issues

This release includes the following known issues:

○ Message Processor backup not backing up the correct set of files (121095148)
HEAD requests to Node.js targets hang (79993247)
○ Create reverse proxy via Open API option is displayed (79949124)
○ Hostnames not resolving (79757554)
○ DataAccessExceptions in multi data center configurations (76087166)
○ Permission error message appears when stopping apigee-postgresql (72379834)
○ MessageLogging policy including extra information in the log message (68722102)

For more information about each of these known issues, including workarounds, see Known issues.

The sections that follow describe each of these topics in detail.

Upgrade paths

The following table shows the upgrade paths for this Feature Release:

From 4.18.01 Directly upgrade from 4.18.01 → 4.18.05
From 4.17.09 Directly upgrade from 4.17.09 → 4.18.05
From 4.17.05 Directly upgrade from 4.17.05 → 4.18.05
From 4.17.01 Upgrade from 4.17.01 → 4.18.01, then upgrade from 4.18.01 → 4.18.05
From 4.16.09 Upgrade from 4.16.09 → 4.18.01, then upgrade from 4.18.01 → 4.18.05
From 4.16.05 Upgrade from 4.16.05 → 4.18.01, then upgrade from 4.18.01 → 4.18.05
From 4.16.01 Upgrade from 4.16.01 → 4.18.01, then upgrade from 4.18.01 → 4.18.05
From 4.15.0x Upgrade from 4.15.0x → 4.16.01, then upgrade from 4.16.01 → 4.18.01, then upgrade from 4.18.01 → 4.18.05

New features

This section describes new features in this Feature Release. In addition to these features, this release includes all features in the Edge UI, Edge Management, and Portal releases listed in Included releases.

In addition to the following enhancements, this release also contains multiple usability, performance, security, and stability enhancements.

JWT Policies

The following JWT Policies are no longer in Beta; they are now GA:

Supported software

This Feature Release includes the following changes to supported software:

  • Red Hat Enterprise Linux (RHEL) 6.9 is now supported
  • Oracle Linux 6.9 is now supported
  • CentOS 6.9 is now supported
  • RHEL/CentOS/Oracle Linux 7.2 are no longer supported

For more information, see Supported software and supported versions.

New Edge experience installation configuration changes

The 4.18.05 release of the New Edge experience contains changes to the configuration file from the 4.18.01 release. The new properties are described in Installation configuration changes from Edge 4.18.01.

Router retry options can now be set at the virtual host level

You can now set retry options for the Router's communications with the Message Processor on the virtual host. This gives you more fine-grained control than the previous options, which were only settable at the Router level.

For more information, see Virtual host configuration properties.

New analytics dimension and change to the x_forwarded_for_ip dimension

The way Edge sets the x_forwarded_for_ip dimension in Edge Analytics has changed. Previously, if there were multiple IP addresses in the X-Forwarded-For header, the x_forwarded_for_ip dimension contained only the last IP address listed. Customers often used the x_forwarded_for_ip dimension to determine the IP address of the client making the API request to Edge.

With this release, the x_forwarded_for_ip dimension now contains the complete list of IP addresses in the X-Forwarded-For header.

Warning: The X-Forwarded-For header has the potential for being spoofed by an IP that has been denied access, except for the last address in the header, which is the IP address Edge received from the last external TCP handshake. To determine the original client IP address making the API request to Edge, this release adds a new dimension to Edge Analytics: ax_resolved_client_ip.

You can now use the ax_resolved_client_ip dimension in a custom report or in a filter condition in a custom report to determine the IP address of the client making the API request. See Analytics metrics, dimensions, and filters reference for more on the ax_resolved_client_ip dimension.

This change also affects the way the AccessControl policy handles the X-Forwarded-For header. In this release, Edge automatically populates the X-Forwarded-For HTTP header with the single IP address it received from the last external TCP handshake (such as the client IP or router). In previous releases, Edge set the X-Forwarded-For HTTP header with the single IP address it received from the first external TCP handshake (such as the client IP or router). For more, see About the X-Forwarded-For HTTP header.

Included releases

Since the previous Edge for Private Cloud Feature Release, the following releases have occurred and are included in this Feature Release:

Edge UI Edge Management/Runtime Portal
18.04.04
18.03.02
18.02.14
17.11.06
18.04.06
18.04.04
18.03.02*
18.02.02
18.01.05
18.04.25.01
18.04.25.00
18.04.23.00
18.03.28.00
18.03.05.00
18.02.15.00
18.01.31.00
17.12.20.00
* Bug fix 74622499 is not included in the Edge for Private Cloud 4.18.05 release.

Click on the links above to see bug fixes and new features from those releases that are included in this Feature Release.

Retirements

This section describes features that were retired in this Feature Release.

API BaaS

API BaaS has been retired. For more information, see Apigee deprecations, retirements, and CPS changes.

Monitoring Dashboard (Beta)

The Monitoring Dashboard (Beta) has been retired and will no longer be supported. As a result, the following components are no longer part of the installation:

  • apigee-influxdb
  • apigee-telegraf
  • apigee-grafana

To continue to get Router, Message Processor, and node metrics, Apigee recommends that you use JMX to integrate Edge for Private Cloud's data with your own monitoring tools. For more information, see What to monitor and How to monitor.

If you upgrade an existing install to version 4.18.05, you should uninstall the Monitoring Dashboard. Apigee does not guarantee that it will continue to function as expected.

Deprecations

The following features were deprecated in this Feature Release.

For more information, see Apigee deprecations, retirements, and CPS changes.

Apigee secure store (vaults)

The Apigee secure store, also known as "vaults," is being deprecated and will be retired in September of 2018.

Instead of using the secure store, use encrypted key value maps (KVMs), as described in Working with key value maps. Encrypted KVMs are just as secure as vaults and provide more options for creation and retrieval.

Adding paths on the API proxy Performance tab

Prior to this release, you could navigate to an API proxy in the management UI, go to the Performance tab, and create different paths for a chart-based comparison on the proxy's Performance tab and in the Business Transactions dashboard.

This feature is now retired and is no longer available in the UI. For an alternative to this functionality, see Alternative to Business Transactions API.

SMTPSSL property for the Developer Services portal

To set the protocol used by the SMTP server connected to the portal, you now use the SMTP_PROTOCOL property, instead of the SMTPSSL property. Valid values of SMTP_PROTOCOL are "standard", "ssl", and "tls".

For more information, see Developer Services portal installation.

Bug fixes

This section lists the Private Cloud bugs that were fixed in this Feature Release. In addition to the bugs listed below, this Feature Release includes all bug fixes in the Edge UI, Edge Management, and Portal releases shown in Included releases.

Issue ID Description
71612599

Memory leak in Message Processors

A memory leak has been fixed. It occurred in Message Processors when Qpidd was stopped.

69711616

Security vulnerability in jackson-databind

The jackson-databind library has been updated to version 2.7.9.1 to prevent a deserialization flaw.

65550638

Prevent user's email address from being changed

You can no longer change a user's email address in the message payload sent to the management API. The management API also now disallows XML in the request body.

Known issues

The following table lists known issues in this Feature Release:

Issue ID Description
121095148

Message Processor backup not backing up the correct set of files

Workaround:

Run the backup a second time and it should back up the correct set of files.

79993247

HEAD requests to Node.js targets hang

HEAD requests to a Node.js target can hang, leaving connections pending.

Workaround:

To work around this issue, define a handler for HEAD requests to explicitly return an empty response.

79949124

Create reverse proxy via Open API option is displayed

The proxy wizard currently displays an option to create a new proxy via Open API. This is not possible on Edge for the Private Cloud.

Workaround:

None.
79757554

Hostnames not resolving

After installing or upgrading Edge for Private Cloud, hostnames might not resolve to their addresses.

Workaround:

To resolve this issue, restart the Edge UI component:

/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
76087166

DataAccessException in multiple data center configurations

In multiple data center configurations, if one datastore becomes unavailable, then you might see the following error:

DataAccessException: Error while accessing datastore;
Please retry later

The result is that Management Server may not start because it is trying to connect to Cassandra nodes in both dc-1 and dc-2. The DataAccessExceptions occurs if a Cassandra node is down. This might also result in API traffic disruption, where Message Processors report DataAccessExceptions while trying to retrieve KVMs.

Note that the expected state is for the Management Server not to connect to datastore components across regions.

Workaround

The workaround is to deregister the following Cassandra node types in the unavailable data center and then re-register them after the Cassandra nodes are available again:

  • kms-datastore
  • dc-datastore
  • keyvaluemap-datastore

To deregister and reregister these Cassandra node types:

  1. Get the UUIDs of the Cassandra nodes by using the following curl command:
    curl -u ADMIN_EMAIL:ADMIN_PW \
      "http://MS_IP:MS_PORT/v1/servers?region=REGION&pod=GATEWAY_POD \
      &type=CASSANDRA_NODE_TYPE"

    Where:

    • ADMIN_EMAIL and ADMIN_PW are the credentials of your Apigee account.
    • MS_IP and MS_PORT are the Management Server's IP address and port number.
    • REGION is the name of the data center in which the Management Server is located.
    • GATEWAY_POD is the pod name, which is by default "gateway". You might have renamed it to something else, though, so check your implementation.
    • CASSANDRA_NODE_TYPE is one of kms-datastore, dc-datastore, and keyvaluemap-datastore.

    For example:

    curl -u nickdanger@google.com:myP@$$w0rD
      "http://192.168.0.1:8080/v1/servers?region=dc-1&pod=gateway&type=dc-datastore"

    The response uses the following format:

    {
      "internalIP" : "POD_IP_ADDRESS",
      "isUp" : [true|false],
      "pod" : "GATEWAY_POD",
      "reachable" : [true|false],
      "region" : "dc-1",
      "tags" : {
        "property" : [ ]
      },
      "type" : [ "kms-datastore", "dc-datastore", "keyvaluemap-datastore" ],
        "uUID" : "POD_UUID"
    }

    For example:

    {
      "internalIP" : "192.168.1.11",
      "isUp" : false,
      "pod" : "gateway",
      "reachable" : false,
      "region" : "dc-1",
      "tags" : {
        "property" : [ ]
      },
      "type" : "dc-datastore",
      "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
    }

    Note the values of the uUID field in the response. You will use these to deregister the nodes.

  2. Repeat step one for each Cassandra node type: kms-datastore, dc-datastore, and keyvaluemap-datastore. Be sure to take note of the UUIDs that are returned.
  3. Deregister the nodes using the following command:
    curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers/UUID" -X DELETE

    Where UUID is the UUID returned in the previous command's response.

  4. Repeat step 3 for each UUID you collected in steps 1 and 2.
  5. Re-register the nodes using the following command:
    curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers -d \
      "Type=kms-datastore&Type=dc-datastore&Type=keyvaluemap-datastore& \
      Type=counter-datastore&Type=cache-datastore&InternalIP=POD_IP_ADDRESS& \
      region=REGION&pod=GATEWAY_POD" -H \
      'content-type: application/x-www-form-urlencoded' -X POST

Note that these operations register and deregister nodes from Zookeeper and do not have any impact on the Cassandra cluster. For more information about these commands, see Update datastore registrations.

72379834

Permission error message appears when stopping apigee-postgresql

When you use the apigee-seriver apigee-postgresql stop command to stop apigee-postgresql, you might see a message saying that apigee-serive cannot change to the user's home dir. You can ignore that message.

Workaround:

N/A
68722102

MessageLogging policy including extra information in the log message

The FormatMessage element of the MessageLogging policy controls the format of the logged message. When FormatMessage=false, the logged message is not supposed to include any Apigee-generated information. However, even if you set FormatMessage=false, the log message still includes the following information:

  • The priority score
  • The timestamp

Workaround:

None.

Next step

To get started with Edge for Private Cloud 4.18.05, use the following links:

New installations:
New installation overview
Existing installations:
Upgrade from 4.18.01
Upgrade from 4.17.05 or 4.17.09
Upgrade from 4.17.01
Upgrade from 4.16.09
Upgrade from 4.16.01 or 4.16.05