You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info
On Sept. 29, 2020, we released a new version of Apigee Edge for Private Cloud.
Updating this release will update the components in the following list of RPMs:
You can check the RPM versions you currently have installed, to see if they need to be updated, by entering:
To update your installation, perform the following procedure on the Edge nodes:
On all Edge nodes:
- Clean the Yum repos:
sudo yum clean all
- Download the latest Edge 4.19.06
curl https://software.apigee.com/bootstrap_4.19.06.sh -o /tmp/bootstrap_4.19.06.sh
- Install the Edge 4.19.06
apigee-serviceutility and dependencies:
sudo bash /tmp/bootstrap_4.19.06.sh apigeeuser=uName apigeepassword=pWord
Where uName:pWord are the username and password you received from Apigee. If you omit pWord, you will be prompted to enter it.
- Update the
sudo /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
- Use the
sourcecommand to execute the
- Clean the Yum repos:
Update all Cassandra nodes:
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
where configFile specifies the configuration file that you used to install Apigee Edge for Private Cloud. For example,
- On all Edge nodes, execute the
update.shscript for the
edgeprocess. To do this, execute the following command on each node:
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
Update Edge UI:
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
- Execute the
update.shscript for SSO on all nodes. On each node, execute the following command:
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
- If you are using the New Edge experience, execute the following command:
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
- If you are using Apigee mTLS, follow the procedure described in
Upgrade Apigee mTLS.
For more information, see Introduction to Apigee mTLS.
Deprecations and retirements
No new deprecations or retirements.
This section lists new features in this release.
Encrypting JMX passwords
The following table lists the bugs fixed in this release:
apigee-mtls certificates were only valid for 30 days.
New certificates are now valid for one year. To upgrade an old 30-day certificate with a new certificate, valid for one year, see Upgrade Apigee MTLS.
An outdated library on enterprise.apigee.com was causing security issues.
The library has been updated.
A set of Java resources at org level was causing message processors to fail to load organizations.
Data masking for HTTP headers was case sensitive.
This has been fixed: data masking is no longer case-sensitive.
Potential vulnerability due to "True-Client-IP" header
This release introduces a new Access Control Policy element,
Some silent variables were misspelled.
Silent install variable
mTLS installation was failing due to a Consul server issue.
Consul binary upgraded from v1.6.2 to latest stable version, v1.8.0.
Audit logs were not showing users whose roles were updated.
After performing role changes for existing users or adding an existing user to an org, the audit log showed "Update user undefined," which prevented you from seeing who the action was performed on.
mTLS installation was failing due to an outdated Consul binary version.
The Consul binary has been upgraded from v1.6.2 to the latest stable version, v1.8.0.
apigee-mtls now properly handles servers with multiple network interfaces and addresses.
apigee-tomcat was not being updated when applying patch updates.
This has been fixed.
Documentation for disabling protocols in the UI was missing.
For new documentation, see Disabling TLS protocols.
The following table lists known issues in this release:
Ldap policy connection pooling issue
LDAP connection pool settings for JNDI configured through the LDAP resource are not reflected, and JNDI defaults cause single-use connections each time. As a result, connections are being opened and closed each time for single use, creating a large number of connections per hour to the LDAP server.
In order to change the LDAP connection pool properties, do the following steps to set a global change across all LDAP policies.
To verify that your connection pool JNDI properties are taking effect, you can perform a tcpdump to observe the behavior of the LDAP connection pool over time.